Is this because you can kind of think of GC - or any dynamic allocation - as an effect? I'm imagining a GC-less language with algebraic effects and handlers might form another alternate foundation here (see how Multicore OCaml uses effect handlers for async scheduling).
Conversation
Yes, looking at GC-ish functions as having a different "color" helps.
But effects are more general, this has to do with GC being something that needs to interrupt execution to change things.
Like a green threading scheduler.
1
1
GC is your code running (lightweight) concurrently with a collector "thread"
1
Yeah, I was kind of wondering if it is like how people learn that single element lists and map/flatMap are handy for expressing nullability in languages without an Option type. Do futures give me more 'structure' than I want for GC?
1
Algebraic effects+handlers do give you interruptable sequencing, afaik (does depend on your system though).
1
Yeah. Bear in mind, the problem being solved here is "rust doesn't like GC bc it pulls the rug out under it"
and async as a solution is good because it is language support for pulling the rug out from under things
1
1
Whether or not it's too much structure depends on what you're using GC for imo. Though "too much" is fuzzy bc the alternatives aren't necessarily great.
1
I think it may work for servo (perf willing) because servo splits out most of its logic out of the dom, and the dom mostly wraps things and does tree manips. It's still *complicated*, but not pervasive.
1
Yeah. I think this is a cool insight at any rate. Could make it easier to work with in Rust at least, given all the work going into async/await.
1
1
Yeah, this is very much a "this improves rust" thing, if you're able to add first class language level support there are easier routes to go
(Though as Graydon mentioned runtimes often internally treat async and GC interruption points similarly)
1
1
Replying to
Yeah, I've been considering adding algebraic effects to my hobby language, and was considering using effects for allocators. This gives me more encouragement, so thanks for sharing! (It's not all roses though - I want zero-overhead handlers somehow, which is kinda tricky)
ooh- before this what was the motivation for using effects for allocators? ability to swap them out, or is there something else?
1
1
More of just a hunch really. Swapping them out` was on the cards too though. And also working cleanly between different capabilities for different platforms, although that suggest I would want coeffects there, but I'm not entirely sure.
1
2
Show replies