I have been thinking about algebraic effects and handlers for low-level systems programming:
Inspired by the way Zig exposes memory allocation pretty pervasively, I was wondering if I'd be able to have allocators be some kind of 'effect' in Pikelet: ziglang.org/#Manual-memory 1/3
Conversation
This leads to an annoying cycle of features however. If effects need to be reified as data, then will yielding effects also require effects? 😳 There are ways to optimise away handlers using inlining and fusion, but this goes to a more fundamental level I think? 2/3
1
So I was wondering: Is there some dual(?) notion to algebraic effects and handlers? Where you inject handlers rather than executing on reified effects after the fact? I think this might look something like how Clean does effects with uniqueness typing: clean.cs.ru.nl/download/html_ 3/3
Replying to
Oh, the other tricky thing is that this would somehow need to interact with some sort of region/borrowing system I'm guessing? 😳 Dunno if a type system like Granule's (granule-project.github.io) could help here 🤔 Waves hopefully at 👋
Replying to
My intuition (which might be off) is that the dual is something like thread-local storage or execution contexts. devblogs.microsoft.com/pfxteam/execut
1
1
i.e., an effect is an interface, a carrier is an implementation of one or more of those interfaces, and you install a particular carrier into TLS before executing the code that uses the effect.
1
1
Show replies
Replying to
It isn’t a dual notion, more a dual implementation strategy. Coproduct of effect data interpreted by product of handlers is not central to algebraic effects, just implementation detail. Fusion for Free does exactly what you describe here, for instance.
1
2
Ahhh cool - yeah I wasn't really sure about that and that's a nice clarification! 😅
1
1
Show replies