It's hard for me to tease apart the differences between Rye "first class context", deprecated JS "with" statement, Scala/Idris/Agda implicit arguments, and I guess also just effect systems generally?
it feels like there're all features for ergonomic dependency injection, but maybe that's a lot of programming
There are differences in the details. JS with is much less powerful than implicit arguments or effect systems. The basic concept is similar; all deal with dynamic scoping in some way.
Effect systems can change control flow (that's the point of many effects, such as exceptions) so they require capturing continuations.
Implicit arguments usually have compile-time search / composition.
Rye contexts seems like they have neither of the above, but I've only skimmed through the description.
> If a word in a context is bound to a function it evaluates it, if not it returns the value bound to it.
One of my favorite compositional patterns! I wish we saw this .ore, not just in contexts but everywhere.
It's something I saw Ansible inventories do that I absolutely loved. Point at an inventory, and Ansible will run it & use the output as inventory, or will otherwise use the contents.
I wish more languages had stuff like this. I just skeeted today that JS should have an optional function invocation syntax. myVar.??(). Run myVar if it's a function else use its value.
The next step from this is in languages like Haskell, where function currying is the same as function calling, and everything is lazy. There's effectively no difference between a function with all the arguments filled out, and the value it returns – at least most of the time you don't need to care about the difference. Partial function application is incredibly ergonomic in the language too.
How do you then distinguish between referring to a function with no / empty arguments, and invoking that function? Functions are no arguments (aka thunks) are useful in a number of contexts (pun intended!) and it's kinda the point that they are not immediately invoked.
Yeah, this kind of automatism turns nullary functions into brittle things where you never know when or how often they get evaluated. Even if you have no side-effects, a potentially expensive computation is in itself a side-effect that you want to control when it happens.
A nullary function is a different type from its return type, and should better be handled as such.
it feels like there're all features for ergonomic dependency injection, but maybe that's a lot of programming