Which, in FP, is all but invisible: the arguments to a function literally are its dependencies.

I think OOP has more primitive concepts (and more mutation) than FP, so dependency injection in OOP also includes object construction and often mocking effectful operations. That's why it gets its own name in OOP, while being more of an ambient idea in FP.

I don't think I agree with that. In scheme you can write (display "hello world") inside a function and this is directed to some globally configured port. If either the port or the display function was passed as a parameter to the function, then it would be dependency injection.

On its face, you're right. You can formalize this approach using dynamically-scoped variables, which is a step on the road toward coeffect systems in typed functional languages. But in a coeffect system, the type of `display` would explicitly call out that its environment must provide the necessary dynamic variables, which brings us back to dependency injection. `display`'s dependencies would be injected via dynamic scope, which you can override in the caller by defining a dynamic binding.

As an alternative, I would suggest that `display` is special, and that instead of thinking of passing an extra parameter to `display`, that the module that calls it should instead have `display` itself injected.

Yes that is actually what I meant, I guess I was not being clear. The function calling "display" could have "display" passed as an argument rather than calling it as a globally defined function.

Relying on dynamic variables would probably not be considered dependency injection. A major purpose of DI is that dependencies should be declared in the signature, making it explicit which dependencies a unction or object depends on.

> A major purpose of DI is that dependencies should be declared in the signature

Yes, and a coeffect system would cause dependencies on dynamic variables to be declared statically, even if they're provided by "the environment" at runtime.

Tomas Petricek's PhD project page is a good introduction to coeffect systems, and it illustrates dynamic variables as an example. http://tomasp.net/coeffects/

I used to restrict DI as dynamic binding but someone told me that for business, having a special category of arguments to be tweaked as see fit is useful. It's variable at the system level maybe ?