Conversation

JT
@jntrnr
This has some good "nerd snipe" potential for programming language designers. In grad school, I was poking around possible solutions to this (though sadly didn't go far enough). A possible direction - modules could expose all of their implied imports to configurability.
Quote Tweet
Jonathan Müller
@foonathan
·
I wrote my thoughts about writing a new type vs adding new functions to change behavior: saturating_add vs. saturating_int – new function vs. new type? foonathan.net/2022/03/behavi #cpp #cplusplus
2
7
JT
@jntrnr
This would mean even operators. You could bring a module into scope and then configure its + over ints to saturate by replacing the implied import (you could think of this similar to capabilities also). This would trickle through additional modules that module uses, and so on.
1
2
JT
@jntrnr
Basically each module has default imports that it draws from where it's imported. On a related note - something that came up the other day in chatting with another Rust dev: you can't easily replace a dependency one of your dependencies use. This means as your project grows...
1
JT
@jntrnr
...you end up taking three different async runtime variations, four different error handling variations, and so on. You can't easily say "this is the one true way", and collapse your transitive deps together. Wouldn't it be nice if there was a solution to both kinds of issues?
4
2
Brendan Zabarauskas
@brendanzab
Replying to
@jntrnr
It's a different approach I think, but wrt. async vs. nonasync, I think OCaml is intending to tackle this with algebraic effects, by being parametric over the effects that functions can yield, and leaving the handling/scheduling up to the caller:
youtube.com
Effective Programming: Adding an Effect System to OCaml
Type systems designed to track the side-effects of expressions have been around for many years but they have yet to breakthrough into more mainstream program...
Twitter Web App