Stream: compiler development

Topic: Cor experiment for effect interpreters and inference

Ayaz Hafiz (Nov 24 2023 at 23:00):

I made a new cor experiment to figure out if I could make a simpler model for effect interpreters to work, and to explore some of the inference changes mentioned in https://roc.zulipchat.com/#narrow/stream/395097-compiler-development/topic/Allowing.20implicit.20cycles.20in.20the.20type.20representation

Ayaz Hafiz (Nov 24 2023 at 23:00):

Here's the compiler

Ayaz Hafiz (Nov 24 2023 at 23:01):

The good news: I got https://github.com/roc-lang/roc/issues/5464 working with an effect interpreter model without lambda sets (see this playground). The IR is kind of insane though, 2K lines of IR for 50 lines of code (admittedly it's sparse)

Ayaz Hafiz (Nov 24 2023 at 23:02):

Also, composable effect interpreters work

Ayaz Hafiz (Nov 24 2023 at 23:03):

Also for some reason the inference/propagation of type aliases is really nice (hover over some variables here to see)

Ayaz Hafiz (Nov 24 2023 at 23:04):

The next step is to see if this can work with lambda sets, and if so, we should probably translate the new algorithms in-place to the compiler. If anyone wants to play around with this and/or hack on it with your own experiments, let me know. The source is https://github.com/ayazhafiz/cor/tree/base/experiments/compose_fx

Richard Feldman (Nov 25 2023 at 00:08):

this is super exciting! :smiley:

does it already do the "record captures in canonicalization for type annotations" thing that turned out to be necessary for lambda set correctness in annotations?

Ayaz Hafiz (Nov 25 2023 at 00:44):

no, neither mutual recursion nor lambda sets are around

Ayaz Hafiz (Dec 10 2023 at 03:30):

For anyone interested, I've still been working on this sometimes in my free time (current playground). I'm having some trouble getting lambda sets working across the board, but you'll see that most examples work (except the #5464 reproducer examples).

Ayaz Hafiz (Dec 10 2023 at 03:31):

The positive news is I think the idea of going full in to equirecursive types and not trying to track "recursion pointers" in the frontend IR (i.e. before the equivalent of Roc's mono IR) is definitely the way to go

Ayaz Hafiz (Dec 10 2023 at 03:33):

And, I think I've found a much easier method for specializing on types than we currently use (@Folkert de Vries recently talked about the annoyance of having to specialize on a per-symbol basis in the current Roc implementation, which seems unnecessary). Obviously this project is only a subset of Roc, but the monomorphizer and IR generator are each like 400 LoC even with lambda sets

Richard Feldman (Dec 10 2023 at 04:30):

I am SO, SO HYPE about this!!!

Richard Feldman (Dec 10 2023 at 04:30):

how are you feeling about the lambda set issues?

Richard Feldman (Dec 10 2023 at 04:31):

tractable but tricky? Or like "still unsure on whether the problems are even solvable" :big_smile:

Ayaz Hafiz (Dec 10 2023 at 05:14):

Probably tractable, but I don't really know how to solve them right now

Luke Boswell (Aug 13 2024 at 07:32):

I've been trying to track down the latest status on effect interpreters... and this looks like the most relevant thread.

Just wanted to clarify something. Is the type erasure work that Ayaz summarised and Sam was looking at related to effect interpreters?

My loose understanding is that we want to upgrade and have type erasure so we can then implement effect interpreters.

Richard Feldman (Aug 13 2024 at 11:03):

yeah, in essence:

• a Task-based concurrency primitive (e.g. Task.map2 or whatever we decide to name it) which actually lets tasks run concurrently requires that Roc's compiler be able to support compiling arbitrary type-erased (and therefore boxed) types in order to store them in tasks
• effect interpreters are blocked on lambda set bugs
• fixing the lambda set bugs seems to require moving lambda set inference into its own pass, which will be a big project and might run into other issues (since lambda sets have run into many issues so far)
• to focus on unblocking things, the plan is to implement type erasure and then use it for all closures (for now) instead of lambda sets. This will make the runtime performance of all Roc programs worse, but should fix a ton of compiler bugs while unlocking Task-based concurrency.
• after landing that, we can reintroduce lambda sets as a separate pass (which is what Morphic does, and their implementation works without bugs as far as we know), and if there are bugs, we can put it behind a CLI flag or env var or something while we work them out, so they aren't blocking projects like they are today

Luke Boswell (Aug 13 2024 at 11:25):

Thank you for summarising. :grinning:

Richard Feldman (Aug 13 2024 at 11:29):

no prob, it's been top-of-mind for a long time - it'll be a huge deal for the language when we have it! :smiley:

Last updated: Jul 06 2025 at 12:14 UTC