justin garcia
LightNews LightNews
banner
purefunctor.me
justin garcia
@purefunctor.me
650 followers 370 following 190 posts
purescript @ oxfordabstracts.com
core team @ purescript.org
organiser @ functional.org.ph

I work on web, compilers, and type systems using FP

🇵🇭 he/him
Posts Replies Media Videos
purefunctor.me
I bought the vinyl!
July 11, 2025 at 9:41 AM
purefunctor.me
I love when abstractions fall right into place
#[derive(Debug, PartialEq, Eq)] pub enum Thing { Annotation(cst::Annotation), Expression(cst::Expression), Nothing, } pub fn thing_at_position(content: &str, parsed: ParsedModule, position: Position) -> Thing { let Some(offset) = position_to_offset(content, position) else { return Thing::Nothing; }; let node = parsed.syntax_node(); let token = node.token_at_offset(offset); match token { TokenAtOffset::None => Thing::Nothing, TokenAtOffset::Single(token) => thing_from_single(token), TokenAtOffset::Between(left, right) => thing_from_between(left, right), } } fn thing_from_single(token: SyntaxToken) -> Thing { token.parent_ancestors().find_map(thing_classify_node).unwrap_or(Thing::Nothing) } fn thing_classify_node(node: SyntaxNode) -> Option<Thing> { let kind = node.kind(); if cst::Annotation::can_cast(kind) { cst::Annotation::cast(node).map(Thing::Annotation) } else if cst::Expression::can_cast(kind) { cst::Expression::cast(node).map(Thing::Expression) } else { None } } fn thing_from_between(left: SyntaxToken, right: SyntaxToken) -> Thing { let left = left.parent_ancestors().find_map(thing_classify_node).unwrap_or(Thing::Nothing); let right = right.parent_ancestors().find_map(thing_classify_node).unwrap_or(Thing::Nothing); match (&left, &right) { // If left/right share an ancestor (_, _) if left == right => left, (_, Thing::Nothing) => left, (Thing::Nothing, _) => right, // Otherwise, lean towards the right (_, _) => right, } }
May 18, 2025 at 11:15 AM
purefunctor.me
Now I gotta figure out how to make the build system parallel
Benchmark results for single core and multi core parsing the entire package set in the purescript-analyzer. 637ms on a single core, 108ms on 12 cores.
May 17, 2025 at 12:21 PM
purefunctor.me
TIL that Option<NonZero<u32>> has the same size as NonZero<u32> and I'm wondering if it's a worthwhile optimisation to make for flattened ASTs?

At 1 billion nodes yeah it'll save 12 GB but at a million 12 MB doesn't matter as much for modern hardware.
// size = 28 bytes pub enum F { F1(Option<u32>, Option<u32>, Option<u32>), F2(Option<u32>, Option<u32>, Option<u32>), } // size = 16 bytes pub enum G { G1(Option<NonZero<u32>>, Option<NonZero<u32>>, Option<NonZero<u32>>), G2(Option<NonZero<u32>>, Option<NonZero<u32>>, Option<NonZero<u32>>), } // 28 * 1_000_000 = 28_000_000 bytes // 16 * 1_000_000 = 16_000_000 bytes // // 12_000_000 bytes -> 12 MB (does it matter?)
May 16, 2025 at 9:19 AM
purefunctor.me
The purescript-analyzer currently hovers around 1.0~1.3 GiB of memory usage for 871k (!!!) lines of PureScript. A good chunk of the memory being allocated comes from the AST, specifically the mechanism it currently uses for flattening the representation.
btop screenshot showing 1.03 GiB memory usage for purescript-analyzer
May 15, 2025 at 5:10 PM
purefunctor.me
been a hot minute since I cooked this good
fn explicit_module_exports( external: &mut impl External, state: &mut State, file: FileId, index: &Index, including_self: bool, ) { if including_self { implicit_module_exports(state, file, index); } for (name, id) in index.iter_term_nominal() { if index.is_term_exported(id) { state.add_term(name, file, id); } } for (name, id) in index.iter_type_nominal() { if index.is_type_exported(id) { state.add_type(name, file, id); } } for (_, items) in index.iter_import_items() { if !items.exported { continue; } let Some(name) = &items.name else { continue; }; let import = external.file_id(name); let exports = external.exports(import); for (name, (file, id)) in exports.terms.iter() { state.add_term(name, *file, *id); } for (name, (file, id)) in exports.types.iter() { state.add_type(name, *file, *id); } } }
April 2, 2025 at 6:15 PM
purefunctor.me
types when you write _help / ?help:
"Th-this is my hole!" "It was made for me!"
April 2, 2025 at 12:57 PM
purefunctor.me
erm
Your system has run out of application memory. Discord 958.9 MB Ghostty 141.25 GB Pages 430.9 MBB Slack 6.58 GB Zen 8.80 GB Finder 84.5 MB
March 11, 2025 at 11:48 AM
purefunctor.me
Instance heads are annoying to lower
// TODO: Implement binding for Instance/InstanceBinder. Here are some cases to handle: // // instance Eq a // // instance TypeEq a a // // instance Ord a => Eq a // // We'll first encounter InstanceBinder when checking the instance head. If we were to // bind the names naively, we'll encounter a case where a name would have already been // bound (see TypeEq a a). We'll need to do some additional bookkeeping to manage // implicit foralls. // // The first time we see an InstanceBinder, we push it into the scope, giving us a de // Bruijn index. Subsequent usages of the InstanceBinder would simply return that de // Bruijn index. Likewise, any usage of Instance would refer back to that type // variable. // // Unlike explicitly-bound type variables, we have no identity to anchor to for // implicit type variables. As such, we must create them on the fly when lowering types // for instance heads. Although, we sort of do in a way? If we used an interner in the // Constraint graph node, we could obtain an ID that's specific to that scope. That // should be a sufficient anchor for de Bruijn indices _that is not_ SmolStr. // // Although, what if type variables didn't resolve to TypeVariableBindingId directly, // but to the scope nodes that they were allocated in? Then, we'll need to perform the // resolution _here_
March 2, 2025 at 6:41 AM
purefunctor.me
Note to self: make sure the binary you're benchmarking bails if it doesn't find the files it's supposed to be using
Benchmark 1: ../target/release/compat Time (mean ± σ): 695.4 ms ± 16.9 ms [User: 595.8 ms, System: 99.1 ms] Range (min … max): 676.5 ms … 725.6 ms 10 runs
February 20, 2025 at 6:53 PM
purefunctor.me
GHC... seems to generate them?
(SK2) All skolemisation (even without DeepSubsumption) builds just one implication constraint for a nested forall like: forall a. Eq a => forall b. Ord b => blah The implication constraint will look like forall a b. (Eq a, Ord b) => <constraints> See the loop in GHC.Tc.Utils.Instantiate.topSkolemise. and Note [Skolemisation en-bloc] in that module
February 18, 2025 at 5:04 PM
purefunctor.me
I was just thinking about how skolemisation would fit in a constraint-generating type checker and I was wondering if it makes sense to use implication constraints for them.
Slide about implication constraints from Simon Peyton Jones' ZuriHac 2019 Keynote https://drive.google.com/file/d/1NRkP0hz-0Yo49Rto70b2nUwxjPiGD9Ci/view
February 18, 2025 at 4:59 PM
purefunctor.me
Why do banks make such terrible software? Like I get hanging on to archaic systems but stuff like this is inexcusable
An alert box that states "User is already logged-in"
February 7, 2025 at 4:58 PM
purefunctor.me
What'd I say about tiny interactions again
February 5, 2025 at 8:09 PM
purefunctor.me
one of the takes of all time
Rust is a programming language, but it's also a way for Marxists to subvert the establishment and overthrow institutions.
February 3, 2025 at 10:41 PM
purefunctor.me
I love let-else
fn lower_expr_value( state: &mut State, module: &cst::Module, index: &IndexingResult, group: &ValueGroupId, ) { let root = module.syntax(); let mut signature_id = None; 'signature: { let Some(signature) = group.signature else { break 'signature }; let Some(signature) = index.source_map.declaration_ptr(signature) else { break 'signature }; let Some(signature) = signature.try_to_node(root) else { break 'signature }; let cst::Declaration::ValueSignature(signature) = signature else { break 'signature }; let Some(signature) = signature.signature() else { break 'signature }; signature_id = Some(lower_type(state, &signature)); }; let capacity = group.equations.len(); let mut equation_id = Vec::with_capacity(capacity); for equation in &group.equations { let Some(equation) = index.source_map.declaration_ptr(*equation) else { continue }; let Some(equation) = equation.try_to_node(root) else { continue }; let cst::Declaration::ValueEquation(equation) = equation else { continue }; let Some(guarded) = equation.guarded_expression() else { continue }; let Some(where_expression) = guarded.where_expression() else { continue }; let Some(expression) = where_expression.expression() else { continue }; equation_id.push(lower_expression(state, &expression)); } dbg!((signature_id, equation_id)); }
February 1, 2025 at 10:58 AM
purefunctor.me
I mean... parsing the entire package set seems to finish around 1.3ms
λ ~/pf/purescript-analyzer/ main* hyperfine -N --prepare "sync" --warmup 100 "./target/release/compat" Benchmark 1: ./target/release/compat Time (mean ± σ): 1.3 ms ± 0.1 ms [User: 0.6 ms, System: 0.4 ms] Range (min … max): 1.2 ms … 1.5 ms 76 runs
January 28, 2025 at 12:42 PM
purefunctor.me
Any neovim plugin recommendations? The last time I used it extensively was 5 years ago
brew install neovim
January 26, 2025 at 12:23 PM
purefunctor.me
I'm just discovering now that a few months ago I wrote a build system that incidentally functions a lot like shakebuild.com

I did know about the Build Systems a la Carte paper but it wasn't until today that I actually gave it a proper read-through (bad habit, working on it)
queryFns ∷ ∀ r. { | QueryFns r } queryFns = { parsedFile: absurd , surfaceFull: surfaceFullImpl , surface: surfaceImpl , interface: interfaceImpl , scopeGraph: scopeGraphImpl , diagnostics: diagnosticsImpl } surfaceFullImpl ∷ ∀ r. QueryFn r FileId SurfaceLower.Result surfaceFullImpl engine id = do parsedFile ← inputGet @"parsedFile" engine id case parsedFile of ParsedTotal m → SurfaceLower.lowerModule m ParsedPartial m _ → SurfaceLower.lowerModule m surfaceImpl ∷ ∀ r. QueryFn r FileId Module surfaceImpl engine id = queryGet @"surfaceFull" engine id <#> _.surface interfaceImpl ∷ ∀ r. QueryFn r FileId InterfaceCollect.Result interfaceImpl engine id = do surface ← queryGet @"surface" engine id InterfaceCollect.collectInterface surface scopeGraphImpl ∷ ∀ r. QueryFn r FileId ScopeCollect.Result scopeGraphImpl engine id = do surface ← queryGet @"surface" engine id { interface } ← queryGet @"interface" engine id ScopeCollect.collectModule surface interface diagnosticsImpl ∷ ∀ r. QueryFn r FileId (Set Diagnostic) diagnosticsImpl engine id = do parsedFile ← inputGet @"parsedFile" engine id surfaceResult ← queryGet @"surfaceFull" engine id interfaceResult ← queryGet @"interface" engine id pure $ DiagnosticsCollate.collateDiagnostics parsedFile surfaceResult interfaceResult
January 23, 2025 at 5:36 PM
purefunctor.me
I thought this felt familiar—isn't this the same mechanism that salsa-rs uses for dependency tracking?
5.2.2 Verifying Step Traces from https://simon.peytonjones.org/assets/pdfs/build-systems-jfp.pdf
January 23, 2025 at 7:54 AM
purefunctor.me
absolute cinema
Build Systems a la Carte presentation slide by Simon Peyton Jones describing how the Task type's polymorphism can be used to extract static dependencies in a single line.
January 23, 2025 at 6:53 AM
purefunctor.me
I live for tiny interactions like these
January 18, 2025 at 11:10 AM
purefunctor.me
It's not often that I use function pointers to shared behaviour in Rust but when I do it ends up pretty cool.
let (name_token, declaration, item_fn, make_fn) = match declaration { TypeDeclaration::Class(d) => ( d.class_head().and_then(|h| h.name_token()), cst::Declaration::ClassDeclaration(d), TypeItem::class_group as TypeItemGroupFn, TypeItem::class_item as MakeTypeItemFn, ), TypeDeclaration::Data(e) => ( e.name_token(), cst::Declaration::DataEquation(e), TypeItem::data_group as TypeItemGroupFn, TypeItem::data_item as MakeTypeItemFn, ), TypeDeclaration::Newtype(e) => ( e.name_token(), cst::Declaration::NewtypeEquation(e), TypeItem::newtype_group as TypeItemGroupFn, TypeItem::newtype_item as MakeTypeItemFn, ), TypeDeclaration::Synonym(e) => ( e.name_token(), cst::Declaration::TypeSynonymEquation(e), TypeItem::synonym_group as TypeItemGroupFn, TypeItem::synonym_item as MakeTypeItemFn, ), };
January 18, 2025 at 10:56 AM
purefunctor.me
About time I did myself a favor!
Shipped Items: Keychron V10 Max with Gateron Jupiter Switches
January 13, 2025 at 6:43 PM
purefunctor.me
I feel like compilers are good benchmark "thing to build" to determine what makes a language great—case in point, syntactic macros to generate a thousand lines of boilerplate code.

Also throw in ADTs and exhaustive pattern matching in there since this macro creates those too.
create_ast_enum!( Expression | ExpressionTyped | ExpressionOperatorChain | ExpressionInfixChain | ExpressionTick | ExpressionNegate | ExpressionApplicationChain | ExpressionTypeArgument | ExpressionTermArgument | ExpressionIfThenElse | ExpressionLetIn | ExpressionLambda | ExpressionCaseOf | ExpressionDo | ExpressionAdo | ExpressionConstructor | ExpressionVariable | ExpressionOperatorName | ExpressionSection | ExpressionHole | ExpressionString | ExpressionChar | ExpressionTrue | ExpressionFalse | ExpressionInteger | ExpressionNumber | ExpressionArray | ExpressionRecord | ExpressionParenthesized | ExpressionRecordAccess | ExpressionRecordUpdate );
January 5, 2025 at 6:01 PM