Sounds quite similar to something you could get with algebraic effects/handlers. Is there a link between them? If I accepted the overhead I would want to go with the more general idea - ie. effects.
Conversation
I still wish we could figure out an almost zero-cost effect/handler system - I want this for the Next Systems Language™.
1
1
I think there's something deeply tradeoff-y in there, cost-wise: dynamic control is inherently undecidable so at some level you either incrementally adjust the coupling during runtime (pervasive tax), or defer reconstructing the coupling until it's needed (slow invocation).
1
1
Indeed. I wonder if it could be compiled away statically, but reified if you only if you actually need it (say, for async scheduling).
2
I want effects when I'm writing tests so I don't need to use mocks or dependency injection, but I want my prod code to be compiled down to what I would write in a procedural language.
1
But then I guess we want reified effects when doing exception handling, so we will need to make a tradeoff there. `Result` passing isn't free, but I don't want an alternative to be any worse than that.
1
(aside: I'm _personally_ pretty much ok with the costs of incremental dynamic propagation, but I'm also ok with the cost of uniform representation in generic code, green threads and even GARBAGE COLLECTION, so put me in the systems-programmer heresy bucket as needed)
1
2
Yeah, I'm undecided. Could be swayed multiple ways. But I ultimately want to be _reliably_ be as fast or faster than other systems langs once all results are tallied, but being far simpler and more expressive. Perhaps there might be some shifting around of costs though 🤔
1
I think Swift for example does some really cool stuff where it uses both monomorphization and single representation for generics.
1
Yes, but it does so at relatively high implementation complexity and a certain loss of predictability in performance. Also requires a runtime type-metadata cache for dynamic application of generics to type args. Good in some contexts, less so in others. Tradeoffs, everywhere :P
1
2
Ah, right. Yes, I'm sure you would be well aware of those trade-offs, having worked on it! The runtime cache seems a bit of a pain for embedded stuff...
*Shrug* I mean .. ask a Rust (or C++) stdlib user how many times they think is the right number to compile-in a fully specialized redefinition of hashmaps for some new type, or how to deal with binary upgrades in the field. Tradeoffs are hard because they're hard.
3