Stream: compiler development

Topic: Type erasure

Ayaz Hafiz (Nov 11 2023 at 16:47):

To get erased closures working across the board, I think we need to

• Add refcounters for erased closures in the llvm backend. I think this is straightforward, but we need to track the layout of the boxed data at the time an erased value ("ErasedMake") is constructed, which is not yet done.
• Add support for erased values in wasm backend, and dev backend. @Brendan Hansknecht do you have a sense for how difficult this would be in the dev backend? The representation of an erased value in the LLVM backend is { function_pointer, boxed_data, refcounter_function_pointer }. Calling an erased closure is an indirect call to the function pointer with the boxed data (the unboxing happens on the callee site)
• Update the ability-specializer to not expect lambda sets unconditionally. I can take this piece.
• Figure out some way to incrementally turn on tests in the same way we do for gen_llvm, etc. There is a compiler flag to turn on erasure but it's not exposed to the user

Brendan Hansknecht (Nov 11 2023 at 16:49):

That shouldn't be too hard to add to the dev backend. Fundamentally just an indirect call and some pointer data twiddling.

Brian Carroll (Nov 12 2023 at 08:58):

For the Wasm backend the call_indirect instruction requires a type signature for the called function.
It's like "call any function that takes two f32s and returns an i32".
So the IR will need to contain enough Layout info to do that. But we'll already need that just to actually pass the arguments and get the return value anyway!
There's a bit of bookkeeping too. All indirect callees have to be listed in a table in the module. But we already support this because of List.map and friends, which indirectly call Roc functions from Zig.

Brian Carroll (Nov 12 2023 at 08:59):

So I don't see any major issues.

Last updated: Nov 08 2025 at 12:13 UTC