Implicits to the rescue? (I don't know anything about implicits but I do know that Scala 3 is pretty rigorously formalized so maybe they are less terrifying now than they initially appeared?).
Conversation
Do you something like Scala 3's context functions? docs.scala-lang.org/scala3/referen - or Scala 2 implicits? IIUC Scala 3 switched to ‘givens’ which are more restricted than implicits.
1
1
I don't think anything more complex than the givens would be needed (from what I can understand). Although, reading a bit, I don't think Scala can implicitly resolve context types this way, only values? Or do I have that wrong? I'm not sure if that changes things fundamentally.
1
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?
1
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 😵💫)
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
Show replies