Okay so functional languages need to thread a lot of function parameters. In languages with algebraic effects, receiving an implicit parameter can be modeled as

Okay so functional languages need to thread a lot of function parameters. In languages with algebraic effects, receiving an implicit parameter can be modeled as an effect (that's what Rust people want to have with capabilities https://www.reddit.com/r/rust/comments/rlmbg2/contexts_and_capabilities_in_rust/ https://www.reddit.com/r/rust/comments/rlmbg2/contexts_and_c... - watered down effects to pass around implicit parameters). In languages with monads (which is another formulation of effects, but reified into a concrete type - monads are to effects like Result is to exceptions), it's the Reader monad Haskell has actual implicit parameters, but while they have a clever implementation they aren't used in practice because they have serious problems - they use type constraints which interacts with type inference in nontrivial ways https://chrisdone.com/posts/whats-wrong-with-implicitparams/ https://chrisdone.com/posts/whats-wrong-with-implicitparams/ So.. in Haskell, people end up using the ReaderT pattern (which is like, you wrap your monad in a ReaderT transformer so you can have implicit parameters threaded everywhere in your program - making some sort of composable globals) https://www.fpcomplete.com/blog/2017/06/readert-design-pattern/ https://www.fpcomplete.com/blog/2017/06/readert-design-patte... And this is all about reducing the boilerplate of threading parameters to functions Bonus: in Emacs lisp implicit parameters are everywhere, because the language uses dynamic binding https://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding https://www.emacswiki.org/emacs/DynamicBindingVsLexicalBindi... this means that any variable that is not a local variable implicitly becomes an implicit parameter (Haskell implicit parameters are a controlled form of dynamic binding). Needless to say this is a mess, but highly appropriate for a moddable environment, like a game or, in this case, an IDE. RMS gives this rationale https://stackoverflow.com/questions/3786033/how-to-live-with-emacs-lisp-dynamic-scoping/3792028#3792028 https://stackoverflow.com/questions/3786033/how-to-live-with... > Some language designers believe that dynamic binding should be avoided, and explicit argument passing should be used instead. Imagine that function A binds the variable FOO, and calls the function B, which calls the function C, and C uses the value of FOO. Supposedly A should pass the value as an argument to B, which should pass it as an argument to C. > This cannot be done in an extensible system, however, because the author of the system cannot know what all the parameters will be. Imagine that the functions A and C are part of a user extension, while B is part of the standard system. The variable FOO does not exist in the standard system; it is part of the extension. To use explicit argument passing would require adding a new argument to B, which means rewriting B and everything that calls B. In the most common case, B is the editor command dispatcher loop, which is called from an awful number of places. > What's worse, C must also be passed an additional argument. B doesn't refer to C by name (C did not exist when B was written). It probably finds a pointer to C in the command dispatch table. This means that the same call which sometimes calls C might equally well call any editor command definition. So all the editing commands must be rewritten to accept and ignore the additional argument. By now, none of the original system is left!