Stream: compiler development

Topic: Should Rust glue support closures for now?


view this post on Zulip Sven van Caem (Jan 08 2025 at 15:57):

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?

view this post on Zulip Anton (Jan 08 2025 at 16:09):

My rewrite of RustGlue.roc is nearing feature parity with old Rust glue

Awesome :)

view this post on Zulip Anton (Jan 08 2025 at 16:09):

I heard closures exposed to the platform are soon to become type-erased closures

Can you link to that?

view this post on Zulip Sven van Caem (Jan 08 2025 at 16:12):

I remember @Luke Boswell mentioning it a while back in dms, I'll see if I can find anything

view this post on Zulip Sven van Caem (Jan 08 2025 at 16:17):

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

view this post on Zulip Anton (Jan 08 2025 at 16:21):

This idea from @Brendan Hansknecht may alter things though: https://roc.zulipchat.com/#narrow/channel/316715-contributing/topic/projects/near/491614327

view this post on Zulip Sven van Caem (Jan 08 2025 at 16:25):

It does sound like it yeah!

view this post on Zulip Sven van Caem (Jan 08 2025 at 16:26):

@Brendan Hansknecht maybe you could weigh in on this? :big_smile:

view this post on Zulip Luke Boswell (Jan 08 2025 at 16:42):

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.

view this post on Zulip Anthony Bullard (Jan 08 2025 at 16:44):

I wonder why that would be the case? Wouldn't we really only need that for application-defined types?

view this post on Zulip Anthony Bullard (Jan 08 2025 at 16:44):

Like generics would need to be type-erased sure

view this post on Zulip Anthony Bullard (Jan 08 2025 at 16:45):

But I wouldn't think a Str => {} would need that

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 16:57):

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

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 17:03):

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).

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 17:05):

I guess that PI, kinda leans us towards a go style solution. Threads and channels with minimal extra orchestration.

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 17:06):

That would not need type erasure.

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 17:06):

Still needs the ability to call closures.

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 17:06):

And refcount them

view this post on Zulip Sam Mohr (Jan 08 2025 at 19:10):

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

view this post on Zulip Sven van Caem (Jan 08 2025 at 19:20):

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.

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 21:16):

Yeah

view this post on Zulip Luke Boswell (Jan 08 2025 at 22:31):

Can someone help me update the issue please? https://github.com/roc-lang/roc/issues/6985

view this post on Zulip Luke Boswell (Jan 08 2025 at 22:32):

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.

view this post on Zulip Brendan Hansknecht (Jan 08 2025 at 22:46):

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