Unformed Delta - programming-languages

First impressions of Lean

Tue, 28 Apr 2026 06:49:00 +0000

Since reading a perfectable programming language I started getting the itch to try actual dependently typed programming languages again.

Haskell is my favorite programming language because it provides one of the strongest type system but my most common frustrations in Haskell are from not having access to stronger types. Dependent types in Haskell are an active research project, but still far away. So when I’ve wanted more power I’ve had to make do with Coq (now Roqc) plus a little bit of dabbling in Idris and Agda.

In my usual fashion, I dove right in without reading the tutorial, hoping my experience with similar languages would take me far enough.

First steps

I started out by just typing out some definitions.

def x : Int := 1
def y : Type := Int
def z : x := 1

I was surprised that the last example failed to compile:

▼ 2:14-2:15: error: failed to synthesize instance of type class OfNat x 1 numerals are polymorphic in Lean, but the numeral 1 cannot be used in a context where the expected type is x due to the absence of the instance above

This was fixable by using:

def y : x := (1 : Int)

I had a bit of trouble figuring out that Eq.refl needed an argument, but nicely _ allows inferring the type:

def x : Type := Int
def y : Int := 1
def z : x = Int := Eq.refl _

Of course, I later discovered that there’s a rfl tactic that allows avoiding this boilerplate.

I also ran into some other surprising sharp edges:

def decrement : Nat -> Nat
  | 0 => n
  | 1 + n => n

Doesn’t compile but this does:

def decrement : Nat -> Nat
  | 0 => n
  | n + 1 => n

It’s cool that it’s possible to pattern match on syntax like this, but it’s annoying that it’s a bit inconsistent.

Lambda Calculus Confluence

Basic syntax out of the way, I started implanting the simply typed lambda calculus.

Debrujin indexes:

inductive Term where
  | var : Nat -> Term
  | lam : Term -> Term
  | app : Term -> Term -> Term

Of course, I can’t implement a full interpreter because I can’t solve the halting problem, so I implement single step semantics:

def step_cbn (t : Term) : Maybe Term :=
  match t with
  | Term.lam _ => Maybe.nothing
  | Term.var _ => Maybe.nothing
  | Term.app (Term.lam body) t2 =>
      Maybe.just $ shift_down 0 (subst 0 (shift 1 0 t2) body)
  | Term.app t1 t2 => match step_cbn t1 with
    | Maybe.just t1' => Maybe.just $ Term.app t1' t2
    | Maybe.nothing => match step_cbn t2 with
      | Maybe.nothing => Maybe.nothing
      | Maybe.just t2' => Maybe.just $ Term.app t1 t2'

There’s several different evaluation orders for the simply typed lambda calculus. I recall that Church-Rosser theorem proves that when a term converges, it always converges to the same term regardless of evaluation order.

inductive ConvergesCBN : Term -> Term -> Type where
  | value : step_cbn v = Maybe.nothing -> ConvergesCBN v v
  | step  : step_cbn e = Maybe.just e' -> ConvergesCBN e' v -> ConvergesCBN e v

inductive ConvergesCBV : Term -> Term -> Type where
  | value : step_cbv v = Maybe.nothing -> ConvergesCBV v v
  | step : step_cbv e = Maybe.just e' -> ConvergesCBV e' v -> ConvergesCBV e v

noncomputable def cbv_implies_cbn_convergence :
  ConvergesCBV e v -> ConvergesCBN e v := sorry

I didn’t end up making that much progress. I also tried big step semantics, but that ended up not being much easier, and after Codex and Claude found several holes in my definitions, that made the theorem unprovable as stated, I gave up.

Ecosystem

Lean’s ecosystem still feels fairly immature.

parser libraries: I use megaparsec/attoparsec in Haskell
- fgdorais/lean4-parser: this provides decent parser combinators, but none of the fancier recovery or error handling offered by megaparsec.
C bindings are possible, but you’ll likely need to implement them yourself
effects: monad transformers are the default way of representing effects; usable, but a far cry from Haskell’s wide variety
tooling quite good, lean --server provides top good tooling even in Neovim. I appreciated this compared with using

A meetup

People writing Lean seem to be very dedicated to verifying things for verifications sake. I love that. I think this is the standard for what should be demanded of our libraries and tools.

I’m curious to try diving into metaprogramming, which I hear is pretty good, but that’ll have to wait for another day.

programming language features (and optimizations)

Fri, 24 Apr 2026 00:12:00 +0000

My dream programming language would be able to express the syntax and semantics of every other programming language idiomatically. In this framing a good programming language would have few builtins¹ but would still be able to manifest many more specific features as library definitions.

I take a very general view of features. Optimizations are included in this list because in order practically exploit the fact that one programming can express the semantics of another, it must be able to match its performance². Thus optimizations are more or less “features” for a programming language; they help determine what the programming language can practically be used for.

Maximizing which features are expressible as part of the standard library, maximizes what users are able to rewrite. If users don’t like the features the language provides in its standard library they can write their own. Such a language is maximally flexible for users.

Of course, actually using custom built features comes at the expense of interoperability with the broader ecosystem. But I think it is better to give users the choice of what they need to interoperate with, rather than artificially restricting it to guarantee good interoperability³.

With a sufficient floor of metaprogramming capabilities, any feature could be implemented as a builtin or as part of the standard library. I collect this list so that I can sort/consider which features are more primitive and which are the most useful to be able to reprogram. Each programming language features thus becomes both a test and an axiom for programming language expressivity.

Meta note: I went through and made a bunch of these notes public. There’s still a lot of links that aren’t public. A lot of the pages themselves are stubs and have highly varying levels of research/detail/revision put into them.

meta programming

Features enabling and enabled by metaprogramming. In some sense these are the most important because they’re what enables implementing features in terms of each other. I’m also interested in evaluating which of these features are the most irreducible.

Features providing metaprogramming ability:

Features implementable by metaprogramming:

embedded query languages, e.g. LINQ
EDSLs in general get better as metaprogramming is better supported by a programming language

Features kind of like metaprogramming in terms of the expressiveness they provide:

working with (generally monadic) effects

This category encapsulates language features that make working with effects easier:

do notation
monad extraction
idiom brackets
lifted versions of boolean operators
dedicated syntax for specific effects
pattern match failures are an effect / parsers via pattern matching
the runtime system should be deeply tied to effect system
Implicit Conversions Between Effects
See also: Effects

working with coeffects

method (/with) notation: relatively undeveloped, but interesting
coeffects can act as interpreters for effects: vague but interesting, method notation has some extra ideas for this
See also: coeffects / consumer effects

concurrency / distributed programming

Working with data

pattern matching:

Accessors / key paths / lenses:

generic/uniform syntax for arbitrary n-functors/lenses

optimizations

evaluation order

types

Primitive types:

basic types: closed vs open types
- structs/record types
- row types (i.e. extensible records)
- coproducts / variants / enums
- polymorphic variants
- recursive (µ) types
- nominative (ν) types
- algebraic data types
dependent types:
- dependent product
- dependent sum
- interval / cubic type theory / univalence
- cumulative universes
linear types

Broader concepts:

type inference (+ list of methods) / elaboration
completeness checking
subtypes / subtyping
structural types
gradual typing / migratory typing
pure functions, mutability
- ST monad

Weird/highly non-standard stuff:

dual type operator
co-completeness checking
self types
Lambda with receiver
probably not practical or interesting: representing types as just namespaces

typeclasses / traits

Typeclass features:

standard library

The main purpose of a standard library is to define the shared vocabulary that all programs can coordinate around. Because more primitive features are implemented as part of the “standard library”, it places an even larger burden on the design of its standard library.

Properties the standard library should have:

layers of primitiveness: that allow giving up progressive amounts of interoperability for the ability to redefine larger parts of the language
facilitate migrations between standard library types to make the decision to include/not-include various things as unimpactful as possible

Must haves:

type safe dates/times/durations
OSString type
theorem proving:
- explicitly unordered containers

Things to consider adding to a type class hierarchy beyond what Haskell has:

modules / scoping

lifetimes / scoping

RAII
defer statement
deconstructors / deinitializers
lifetime annotations ala rust
borrow checker
move semantics (e.g. consume in Swift)

control flow

implementing control flow as library functions
loops:
- for loops
- foreach loops
- while loop
- until loop
- do while loop
- unconditional forever loop
- do while with block loop
if statements
switch / case analysis statements
allowing statements to be used as expressions
defer statement
try { … } catch { … }

Dis-preferred:

code location / relocating code

removing indentation from nested code structures
unit tests can be co-located with code
get calling function location
defer statement is useful for putting de-initialization next to initialization logic

testing

unit tests can be co-located with code
inspection testing
unit tests can be discovered at compile time / in the IDE without necessarily running arbitrary code

an expressive programming language

Wed, 08 Apr 2026 05:43:00 +0000

Thanks to Alok Singh for the rough format and inspiration to write this post.

I tried naming as may programming languages as I could and came up with these before I got bored: C Rust Perl Bash Zsh Fish Zig C++ D Visual Basic Prolog Racket Elisp VimScript Lua Ruby Idris Agda Rocq C# F# F* Clojure Kotlin Scala Java ECMAScript TypeScript Raku Python OCaml Standard ML Jai Pony koka Cyclone Unison Swift Objective C Piet J APL Brainfuck Purescript Elm JIF (Java Information Flow) moss LLVM CUDA MLIR x86 ARM MIPS

But Haskell is my favorite.

Why?

It’s expressive. Things that other languages must implement as builtin features, can and are implemented as libraries. This gives you the power to customize the language however you see fit.

In most languages the and && operator needs special compiler treatment to ensure that false && doSomethingExpensive() doesn’t evaluate doSomethingExpensive() unnecessarily. In Haskell laziness gives you this for free. The && operator can be defined in the standard library just like any other function without any special compiler treatment:

(&&) :: Bool -> Bool -> Bool
True  && b = b
False && _ = False

If you evaluate False && someExpensiveComputation, laziness means that the second clause never evaluates someExpensiveComputation, the computation only needs to see that the first argument is False to produce its result.

But there’s a problem with laziness. It makes it hard to predict what order things will get evaluated in, because you need to look at the implementation of your function to know what order its arguments will be evaluated in. For IO like reading a file or printing to the console you need a way to guarantee the order things run in. Haskell adopted do notation and monads for this purpose. But it turns out that it’s a very general abstraction that generalizes exception handling, async/await, generators (e.g. yield), and many other things.

But so far we’ve only listed two language features: laziness and monads. By “avoiding success at all costs” Haskell has accumulated decades of experimental language features produced by programming languages research. This allows Haskell to absorb features and express patterns invented in pretty much any other programming language.

RSpec is a Ruby library for writing unit tests. It lets you describe the behaviors of your program using near natural language syntax.

RSpec.describe Order do
  it "sums the prices of its line items" do
    order = Order.new
    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(1.11, :USD)
    )))
    order.add_entry(LineItem.new(:item => Item.new(
      :price => Money.new(2.22, :USD),
      :quantity => 2
    )))
    expect(order.total).to eq(Money.new(5.55, :USD))
  end
end

Without even needing to resort to macros HSpec embeds a very similar syntax:

spec :: Spec
spec = describe do
  it "sums the prices of its line items" do
    let order = orderFromEntries
      [ LineItem
          { price = Money { value = 1.11, currency = USD }
          , quantity = 1
          }
      , LineItem
          { price = Money { value = 2.22, currency = USD }
          , quantity = 2
          }
      ]
    orderTotal order `shouldBe` Money { value = 5.55, currency = USD }

There’s even database libraries like squeal that embed SQL syntax in a type safe way without needing macros:

getUsers :: Statement DB () User
getUsers = query $ select_
  (#u ! #name `as` #userName :* #e ! #email `as` #userEmail)
  ( from (table (#users `as` #u)
    & innerJoin (table (#emails `as` #e))
      (#u ! #id .== #e ! #user_id)) )

Personally that’s too many operators and too complicated types even for me, but I like the idea that it’s possible in the programming language I use. Maybe someday I’ll have a problem for which that complexity is worth it. The thing that I love the most about Haskell is that people do these things even if its not worth it.

Through clever encodings, it’s even possible to do anything you can do in a dependently typed programming language/proof assistant like Lean and Rocq with a little bit extra boilerplate.

The languages with features I envy

When writing Haskell, there’s still some languages left with features that I envy:

Any programming language with fast compile times: I used to work at a company with a ~2 million lines of code Haskell codebase. It took 3-4 hours to compile from scratch.
True dependently typed programming languages (like Lean, Idris, Agda, Rocq) are way more ergonomic for any kind of advanced type level programming. Haskell’s working on becoming Dependent Haskell, but it’s still a really long way off.
Languages with better macro systems, mostly Racket, who’s macro system is powerful enough to implement Hackett, a #lang pragma that more or less implements Haskell in Racket.
Rust: while Haskell has linear types, they are not nearly as mature as Rust’s uniqueness types for resource management.
Prolog: logic programming can be more declarative than laziness.

My dream is a programming language that can subsume all of these features.

Epilogue

I’m not sure there is a perfect programming language, nor will there probably ever be. Perhaps someday there’ll be a programming language that combines all the features I like. Perhaps Lean will be perfected. But who knows, for now Haskell is still my favorite programming language.