The plan is to give users control through the Allocate effect which can be handled in any way desired as long as it returns some memory. It is similar, but easier to use since it is an effect, to zig's approach of "pass the allocator everywhere." I say easier to use since effects are automatically passed around where necessary and propagated via function signatures and can be inferred.
The specific design is still in question though. For one, an effect like Allocate will be almost ubiquitous throughout each function so care is needed to not clog up signatures too much. There's a few potential solutions here if you're interested. From including Allocate within the row-type of a larger effect like `IO = can Allocate, Read, Write, ...` to encouraging effect inference on functions versus manual annotation.
Here the `Allocate` effect is just a syntactically-lightweight way of doing dependency injection, right? Similar to a Haskell type class. I don't see why you'd need to make it an algebraic effect, as it does not need to mess with control flow AFAIK.
The specific design is still in question though. For one, an effect like Allocate will be almost ubiquitous throughout each function so care is needed to not clog up signatures too much. There's a few potential solutions here if you're interested. From including Allocate within the row-type of a larger effect like `IO = can Allocate, Read, Write, ...` to encouraging effect inference on functions versus manual annotation.