My rewrite of RustGlue.roc is nearing feature parity with old Rust glue (only missing NullableUnwrapped tag unions and closures). I heard closures exposed to the platform are soon to become type-erased closures, which would simplify its glue code a lot (I'm not even sure the glue platform supplies enough information to correctly generate glue code for them at the moment). Would it be better to leave closures unimplemented for now until those changes hit?
My rewrite of RustGlue.roc is nearing feature parity with old Rust glue
Awesome :)
I heard closures exposed to the platform are soon to become type-erased closures
Can you link to that?
I remember @Luke Boswell mentioning it a while back in dms, I'll see if I can find anything
Hm, I'm only finding talk of replacing lambda sets with erased closures entirely (before ayaz cracked lambda sets and that plan was reverted). Perhaps a misunderstanding on my part then
This idea from @Brendan Hansknecht may alter things though: https://roc.zulipchat.com/#narrow/channel/316715-contributing/topic/projects/near/491614327
It does sound like it yeah!
@Brendan Hansknecht maybe you could weigh in on this? :big_smile:
See https://github.com/roc-lang/roc/issues/6985
We needed type erasure for Task.map2
... which I assume may no longer be require with purity inference??
@Ayaz Hafiz do we still need type erasure? It's also the only way to pass functions over the host boundary I thought.
I wonder why that would be the case? Wouldn't we really only need that for application-defined types?
Like generics would need to be type-erased sure
But I wouldn't think a Str => {}
would need that
I don't think the glue revamp really affects this. At least not now. Long term, we will need to expose roc c abi functions to increase the refcounts of closure captures. I'm not sure if we need to expose anything to call the closure. Oh actually I think we plan to box the closures. That may actually simplify things and mean their refcounting works the same as box
I think type erasure would only be needed if we want many different shaped functions to fit in the same shaped hole.
I think this would be equally needed/equally not needed in the purity inference world.
We still want a map2 shaped solution to enable parallel execution (though I guess we could do a more raw thread style solution). Also, given results are not lazy like task, it definitely has to be shaped differently. For that to work, either we need type erasure, we need to box all the inputs and outputs, or we need to make the parallel executions all be {} => {}
(only inputs are captures and outputs have to be through channels or some other mechanism).
I guess that PI, kinda leans us towards a go style solution. Threads and channels with minimal extra orchestration.
That would not need type erasure.
Still needs the ability to call closures.
And refcount them
I still kinda own type erasure, but I'm trying to prioritize the re-canning work for now. Once we have the new compiler pipeline at least mostly ready, I can coordinate with Ayaz to see how accurate the plan in his type erasure proposal is for implementation, and then jump on that if we need it
It sounds like the current approach to exposing Roc closures to the platform will stay the same, at least for the foreseeable future? If so, I'll see if I can make any headway improving rust glue's support for them.
Yeah
Can someone help me update the issue please? https://github.com/roc-lang/roc/issues/6985
If we no longer need it, then it'd be good to add the context and close. Or maybe state that it needs further design review/discussion and we can close and make a new one in future.
Yeah, I think it needs further discussion. Really depends how roc decides to support concurrency in the future. There are paths that don't need it, but it is unclear what path will be recommended.
Last updated: Jul 06 2025 at 12:14 UTC