edmundsmith

Things I wish $Lang had

Sometimes, when programming, I notice that I'm missing some useful features, or when reading I think 'this would be really useful to be part of $Lang'.

Explicit order-invariance and synchronisation points

C compilers are part of why C is hard. They re-order statements based on what appears to be a magic black box. Understanding what's in that black box is much harder than it should be. Many statements (or expressions) in programming act completely independently of each other, and thus their order of execution should not matter. Meanwhile, other statements can depend on the execution of a previous statement (/expression). It would be nice to see the execution dependency graph explicitly and syntactically laid out, rather than being inferred from analysis or assuming every statement to induce a synchronisation point.

Some languages get part of this right. Haskell's laziness means order of execution doesn't need to match the order it's written down, and its purity means that orde

edmundsmith

Follow-up to Method on Emulating Higher-Kinded Types (HKTs) in Rust

First off, thanks for all the comments and kind words on the original writeup; I've been meaning to follow up on some of the suggestions and write about the different ways to represent monads (and functors, HKTs, etc) that now exist, but a month of being busy has kind of gotten in the way (mainly with three new kittens!).

And for sure, I do not expect (nor do I want) this to become the norm for production-level Rust: rather, I hope that this can contribute to the foundations of programming with higher-level abstractions in Rust, somewhat like how early template metaprogramming in C++ and typeclass-constraint-unification metaprogramming in Haskell have contributed, perhaps indirectly, to later innovations in their respective languages and ecosystems that were much more reasoned, sound and usable.

Changes, Edits, Refinements

One of the things suggested in the com

edmundsmith

Method for Emulating Higher-Kinded Types in Rust

Intro

I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.

There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.

As an example, currently we can express this type: