monadic icon indicating copy to clipboard operation
monadic copied to clipboard

A monad transformers library for OCaml, based on transformers and mtl

  • Monadic

    Monadic is a Monad library for OCaml. It implements its monads as Monad Transformers, so you can nest them together for powerful computation expressions.

    It focuses on implementation simplicity, DRYness, extensibility, in leveraging the new OCaml syntax sugars (~let+~, ~and+~, and ~let*~), and in documentation.

** Simplicity

The library will not have any dependencies besides dev-dependencies that help on editor support, such as ocaml-language-server.

If it uses unusual module-level or type-level programming, it will be well documented so that client users can use the same sort of tricks on their extensions.

** DRYness

As much as possible, the library will try to avoid code repetition.

** Extensibility

The library aims at simplicity so that users can implement their own Monadic-compatible monad transformers. For instance, one might want to implement a Lwt-based monad transformer, so that they combine the Option transformer with async-based programming. The library should make that easy, and document the steps necessary to do that. One might even release this extension as a library.

** New OCaml syntax sugars

The new OCaml syntax sugars, perhaps inspired by Haskell's ~do~ syntax and F#'s computational expressions, helps making monadic code look a lot prettier. The sugar was the inspiration for this library even existing. ReasonML and BuckleScript already support OCaml 4.08, but ReScript still doesn't. So the library will not work on ReScript.

** Documentation

While this library aims at having simple implementation, the documentation should be extensive. People should be comfortable with using monad transformers in OCaml.

** Comparison with [[https://github.com/rgrinberg/ocaml-mtl/][ocaml-mtl]]

*** Feature-set

For now, MTL (being older) is more feature-complete. On the other
hand, its documentation is sub-par, and it hasn't been updated for
a long time. Its implementation details are also quite complex.

Here is a list of monad transformers in each library:

| Transformer                  | Monadic | MTL |
|------------------------------+---------+-----|
| Identity                     | [X]     | [X] |
| Option (called Maybe in MTL) | [X]     | [X] |
| Result (called Error in MTL) | [X]     | [X] |
| Reader                       | [X]     | [X] |
| State                        | [X]     | [X] |
| Writer                       | [X]     | [X] |
| RefState                     | [X]     | [ ] |
| List                         | [X]     | [X] |
| ZipList                      | [X]     | [ ] |
| Array                        | [X]     | [ ] |
| ZipArray                     | [X]     | [ ] |
| Seq                          | [X]     | [ ] |
| ZipSeq                       | [X]     | [ ] |
| Continuation                 | [ ]     | [X] |
| Ref                          | [ ]     | [X] |
| Tree                         | [ ]     | [X] |

**** Some observations:

 RefState in Monadic is simply a State monad implemented
 internally by using a Ref instead of passing a tuple ahead in the
 context. Sometimes it might be more efficient as a regular State,
 but you should validate it yourself before deciding for one or
 the other.

 ZipList is an applicative, and doesn't have a monadic interface. It's
 similar to List, but it acts on zips of the two lists, instead of
 expanding like lists do. Same for ZipArray and ZipSeq, which are
 similar to Zip, but act on Arrays and Seqs, of course.

 Continuation will probably never be implemented in Monadic, given
 it introduces a lot of complexity on the implementation side of
 every transformer. I'll consider it in the future if I can think
 of a simple implementation.

 Ref, from MTL, is a structured State monad where you have a
 Dictionary where the keys are integers and the values are
 parameterizable. This seems redundant of a usage of State + lens,
 and goes against the simplicity of the library.

 Tree is also not being implemented, given that it doesn't have a
 Stdlib implementation, and it's better for the user to implement
 it as an extension to the library, using whatever Tree library
 they want to use.