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
3
1
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
This is similar to an old pattern in C code of installing an allocator for the whole process: libcork.io/0.15.0/allocat
Or how in Rust, there will be an async executor installed for the duration of an event loop: docs.rs/tokio/0.1.22/t
1
1
Yeah, not sure if I'm using 'dual' in the right sense here! I was linked this paper which seems to describe a way of compiling effects and handlers into the above style:
Quote Tweet
Replying to @brendanzab
There was the recent ps.informatik.uni-tuebingen.de/publications/s and some other papers at ICFP2020
2
1
