I’d have liked to see the use of dependency injection via the effects system expanded upon. The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.

Also, I had no idea that the module system had its own type system, that’s wild.

Haskeller here!

> The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.

The article appears to have described the free monad + interpreter pattern, that is, each business-logic statement doesn't execute the action (as a verb), but instead constructs it as a noun and slots it into some kind of AST. Once you have an AST you can execute it with either a ProdAstVisitor or a TestAstVisitor which will carry out the commands for real.

More specific to your question, it sounds like the pattern matching you mentioned is choosing between Test.ReadFile and Test.WriteFile at each node of the AST (not between Test.ReadFile and Prod.ReadFile.)

I think the Haskell community turned away a little from free monad + interpreter when it was pointed out that the 'tagless final' approach does the same thing with less ceremory, by just using typeclasses.

> I’d have liked to see the use of dependency injection via the effects system expanded upon.

I'm currently doing DI via effects, and I found a technique I'm super happy with:

At the lowest level, I have a bunch of classes & functions which I call capabilities, e.g

  FileOps (readTextFile, writeTextFile, ...)
  Logger (info, warn, err, ...)
  Restful (postJsonBody, ...)

At the next level up I have classes & functions which can know about the business (and the lower level capabilities)

  StoredCommands (fetchStoredCommands) - this uses the 'Restful' capability above to construct and send a payload to our business servers.

I associate CliApp to all its actual implementations (low-level and mid-level) using type classes:

  instance FileOps CliApp where
    readTextFile  = readTextFileImpl
    writeTextFile = writeTextFileImpl
    ...

  instance Logger CliApp where
    info = infoImpl
    warn = warnImpl
    err  = errImpl
    ...

  instance StoredCommands CliApp where
    fetchStoredCommands = fetchStoredCommandsImpl
    ...

I can create a CliTestApp which has a different set of bindings, e.g.

  instance Logger CliTestApp where
    info msg = -- maybe store message using in-memory list so I can assert on it?

The low-level prod code (capabilites) are allowed to do IO, as signaled by the MonadIO in the type sig:

  readTextFileImpl :: MonadIO m => FilePath -> m (Either String Text)

  readTextFileTest :: Monad m => FilePath -> m (Either String Text)

Another way of looking at it is, if I invent a new capability (e.g. Caching) and start calling it from my business logic, the CliTestApp pointing at that same business logic will compile-time error that it doesn't have its own Caching implementation. If I try to 'cheat' by wiring the CliTestApp to the prod Caching (which would make my test cases non-deterministic) I'll get another compile-time error.

Would it work in OCaml? Not sure, the article says:

> Currently, it should be noted that effect propagation is not tracked by the type system