https://github.com/Denommus/monadic
A monad transformers library for OCaml, based on transformers and mtl
https://github.com/Denommus/monadic
Last synced: 8 months ago
JSON representation
A monad transformers library for OCaml, based on transformers and mtl
- Host: GitHub
- URL: https://github.com/Denommus/monadic
- Owner: Denommus
- License: mit
- Created: 2020-09-12T23:43:35.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2022-06-23T12:09:32.000Z (over 3 years ago)
- Last Synced: 2024-08-04T01:28:40.397Z (over 1 year ago)
- Language: OCaml
- Size: 74.2 KB
- Stars: 19
- Watchers: 4
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.org
- License: LICENSE
Awesome Lists containing this project
- awesome-list - monadic
README
* 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.