[platz]

the monad example in 1ML is:

  type MONAD (m : type ⇒ type) =
  {
    return a : a → m a;
    bind a b : m a → (a → m b) → m b
  };

  map a b (m : type ⇒ type) (M : MONAD m) (f : a → b) (mx : m a) =
    M.bind a b mx (fun (x : a) ⇒ M.return b (f x)) (* : m b *)

not too bad.. though I wonder if things are defined structurally instead of nominally, which monad instance are you going to get for a given expression. Haskell's "one instance per class" rule means the compiler figure out which monad instance to apply.

This looks more flexible, but also looks like it will require more annotations and explicit parameters.

[iskander]

If you combine this with [modular implicits](http://www.meetup.com/NYC-OCaml/events/222026251/), which are hopefully going to be added to OCaml soon, then you'll get something which is nearly as syntactically neat as type classes but more powerful.

[platz]

More power in terms of flexibility, but the mechanism of implicits makes it less clear which instance is in scope for a given expression.

With true typeclasses, there is no ambiguity which instance will be selected (there can only be one)

This distinction is often lost when comparing true type classes with their emulation via implicts.

Sometimes "more power" is not what you want i.e. this is more of a tradeoff.

[andolanra]

The proposed OCaml implementation of modular implicits[1] considers ambiguity a compile-time error, so in that case you'd have to manually indicate which module you're passing in. (This is in contrast to Scala, in which there's an elaborate mechanism for resolving ambiguity in implicits which makes it hard to know which is being selected.)

So the OCaml implementation shouldn't make it any more difficult to discover which implicit is in use in a given context, because if an implicit is used, then it must necessarily be unique and there will be no ambiguity.

[1]: http://www.lpw25.net/ml2014.pdf

[platz]

the section "6.5 Modular type classes" was very interesting. Although they did mention some restrictions as well.

[tel]

You have to explicitly pass the monad "vtable". If 1ML also grabs up modular implicits then you'll have a sensible way of passing implicit arguments not exactly unlike that of Haskell, but modularity and global canonicity are at odds so you have a more complex reasoning task.