Hmm ok. I think I was imagining the custom allocator could be a context param. Still unsure what you think Scala 3 would specifically bring to the table here?
Conversation
I mostly have just heard that implicits had a lot of theoretical issues in Scala 2 that were resolved in Scala 3, so I figured if Rust were going to learn from an implementation of implicits that would be a better place to start.
2
The main reason I'm dubious about allocators as context parameters is what I alluded to elsewhere, I'm not sure how they would play with the borrow checker. We have one implicit context parameter already (for async/await) and it only works in fairly restrictive settings.
1
1
Ahh fair. I would be interested to see experimentation into using Algebraic Effects for allocators, but no clue if that is even possible haha (sounds tricky).
1
I'm pretty sure the ambient allocator is more of a coeffect (though I don't know if anyone's specifically called it that before).
2
I thought they might have been coeffects (although I didn't use the name) but people disagreed with me – see reply to this:
Quote Tweet
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
Show this thread
1
I don't actually see anyone disagreeing with you there, exactly? I could be wrong though. But I know that typeclasses and implicits are both considered coeffects in at least some contexts.
1
Ohh I probably misunderstood then (I usually misunderstand stuff eheh 😵💫)
1
blog.ezyang.com/2020/08/dynami is pretty explicit about it.
1
1
Anyway I guess *ideally ideally* I'd want context parameters that exploit parametricity somehow... like I can pass my context to f<T>(g: impl FnMut) and know that as long as f doesn't know T concretely, g can ignore f's choice of allocator and just use what's in lexical scope.
1
(I may not be explaining clearly, and I'm also realizing that the implicit types would probably need something like "dual Fn/FnOnce/FnMut" to specify how they are borrowed by the closure context. I'm sure this all fails horribly in practice :P).
1
Maybe gotta experiment in a toy language to see how it works. Still want to convince the folks making Granule that allocators might be interesting to look at.
1