- How to read inference rules
- Polymorphic variant inference that beats OCaml
- How to implement effect handlers
- If there is one piece of advice about type inference I think everyone should hear it's absolutely this
- Distinguish between unification variables and skolems or I'm going to keep yelling at you. (feat. a terrible error message in Elm)
- Apparently Polaris' constraint solver is non-confluent
- Closed Type Classes
- Passing closures to programs
- Trees that Grow
- I really don't like let generalization
- The Vega Programming Language
- Polaris' type class instances can close over local variables
- It's wild how easily imperative languages leak implementation details
- Rebuild Patterns
- Higher rank polymorphism despite monomorphization
I was originally going to do this on new years and call it "2024 Edition", but since that's not going to happen anymore, here are some more posts that I like
- Functional programming languages should be so much better at mutation than they are
- Type systems should be consistent (and probably dependently typed)
- Flora's effect handlers
- Function coloring is good actually
- I don't think people appreciate the tradeoffs they're making with algebraic data types
- Haskell's tuples should behave like multi-element newtypes
- Namespaced De Bruijn indices for duplicate record fields
- I feel like noone ever mentions a massive advantages of direct-style effects
- How is Racket the only serious "multi-paradigm" programming language
- (==) is overrated
- I feel like most OCaml programmers have a very different idea of what polymorphic variants are meant to do than I do
- It's honestly kind of strange that the conventional wisdom is "you don't need types for one-off scripts"
- TemplateHaskell crimes
- Let generalization saves the day
that's a topic we've been meaning to understand for quite some time