Proposal: add a dependency injection feature to the language

[pwtail]

Hi @lpil,

I have a nice idea of a dependency injection feature. A dependency-getter can be defined with a function:

fn get_dependencies(target, names_of_deps) {
  // ...
}

names_of_deps are names of the dependencies - a tuple. For example, we can have a jwt_auth function as a getter, and the deps could be user, his permissions and the additional info. The target arg would be the http request.

Normally, the getter function would be called like this:

let #(user, permissions, info) = jwt_auth(request, #("user", "permissions", "info"))

I propose a special syntax for this:

let jwt_auth(user, permissions, info) = request

Or, if we only need the user dependency, we shall write

let jwt_auth(user) = request

And the underlying function call will be

let #(user) = jwt_auth(request, #("user"))

What do you think?

[lpil]

Hello! I'm keen to understand the proposal better.

What would let jwt_auth(user, permissions, info) = request do differently to let #(user, permissions, info) = jwt_auth(request, #("user", "permissions", "info"))

What would be the type of the jwt_auth function in this case?

[pwtail]

These 2 lines of code are equivalent, they should be different in nothing.

jwt_auth could look like this

fn jwt_auth(req: Request, dep_names: Tuple(String)) {
  // try to authenticate the user
  // ...
  fn(dep_name: String) {
    case dep_name {
      "user" -> the_user
      "permissions" -> his_permissions
      "info" -> additional_info
    }
  } |> map(dep_names, _)
}

Actually, I have rethought this and no longer think this is an idiomatic functional way. But would be grateful if you let me know what you think.

[lpil]

I'm interested in the return type of that function, it seems like it wants to try and a different type depending on the input.

If the two syntaxes do the same thing I think it's better not to have a second syntax. Having only one way of doing things make the language more consistent and easy to learn.

[pwtail]

The return type is a tuple of things of different types, yes.

[pwtail]

I agree with you here, and the first reason is of course that there are alternative ways to do the same. But the second is that I've got a much better idea: #2102 Please have a look at it!

[darky]

Totally agree, Dependency Injection is required for referential transparent programs with mocked IO and well covered with unit tests.
Usually, in FP world, Reader monad used for this purpose.

[lpil]

Passing an argument to a function is the way to go. Implicitly supplying a reader monad is just syntactic sugar for this with some additional runtime cost to access the inner value.

Usually, in FP world, Reader monad used for this purpose.

You're confusing Haskell with function programming more generally! The reader monad is very rare in FP, it only largely exists in a few FP niches.

[darky]

Anyway, I implemented my bicycle, inspired via Reader monad
Functional programming Context for Gleam, something like Dependency Injection from OOP world.
Maybe will be useful for someone
BTW, also exists TypeScript, Golang implementations