We present modular implicits, an extension to the OCaml language for ad-hoc polymorphism inspired by Scala implicits and modular type classes. Modular implicits are based on type-directed implicit module parameters, and elaborate straightforwardly into OCaml's first-class functors. Basing the design on OCaml's modules leads to a system that naturally supports many features from other languages with systematic ad-hoc overloading, including inheritance, instance constraints, constructor classes and associated types.
Metadata: arXiv. Abstracts retain their original authors’ rights.
In the conversation
Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels
- Extremely dated: we have almost one new release every six month and in recent releases, the language runtime has been changed and user-defined effects have been introduced.
- No HKTs "in your sense" but: ```ocaml module type S = sig type 'a t end `` `type 'a t` is an Higher Kinded type (but in the module Level). - No typeclasses, yes, for the moment but the first step of https://arxiv.org/pdf/1512.01895 is under review: https://github.com/ocaml/ocaml/pull/13275 - no call-site expansion ? https://ocaml.org/manual/5.0/attributes.html look at the attribute `inline`.
> Ocaml messed up with their operators. ... I hope a future version adds module typeclasses
Do you mean modular implicits?[1] The original paper was published in 2014. There's an internship report from 2023 that summarizes the design and implementation issues:
https://modular-implicits.github.io/report.pdf
[1] https://arxiv.org/abs/1512.01895
Type classes are useful but can be overly restrictive as implemented in languages such as Haskell. In particular, Haskell prevents multiple implementations of a type class for a particular type (a property called canonicity). But there are lots of situations where there are many reasonable implementations of a type class for a particular type.
I hadn't seen a great type-safe way to support ad hoc polymorphism until I read about [modular implicits][1] in OCaml. In situations where there is a reasonable module that satisfies a specified signature for the type of an argument, the module can be inferred.
[1]: https://arxiv.org/pdf/1512.01895.pdf
* GADTs: generalized algebraic data types. As the name suggests, GADTs broaden the set of type-level constraints that one can encode using ADTs. A canonical example involves using GADTs to strongly type an AST and evaluator function s.t. attempting to construct or operate on an invalid AST, e.g., one that represents addition between a boolean and an integer, is a compile-time error [1]. Another great tutorial on GADTs is [2].
* Row polymorphism: statically type-checked duck types, for lack of a better description. In dynamic languages like python or javascript, it's common to pass dict or dict-like objects to functions and have them extract the key/value pairs that they…
Read the full comment
need. Row polymorphism lets you have your cake and eat it too by enforcing enough structure to ensure that functions only receive records containing all relevant keys — without requiring that functions take a specific concrete type.
* First-class modules: another tool for type-level programming and modularity. I won't say much since it's hard to understand why you want and at times need them until you've organically come across a use-case for them. Once you do, you'll wish that other languages had them. Here's a resource, though: [4].
* Let binding operators: these let you define your semantics for binding values to variables. A common use-case is defining let* as the monadic bind operator for some type: let (let*) x f = bind x f, after which writing monadic functions is way more pleasant syntax-wise. In contrast to the other items on this list, this is pure syntactic sugar but incredibly impactful [5].
* Algebraic effects: the conceptual root of concepts such as generators (yield), async/await, and checked assumptions. Informally, they're (among other things) a way to encapsulate computation and jump around code like a goto statement, but in a more structured and type/memory-safe way [6].
* Modular implicits: these allow (among other things) ad-hoc polymorphism, meaning that the same operator, e.g. (+), can operate on both integers and floats. That's the oft-cited use-case, and it sounds pedestrian, seeing as most mainstream languages with weaker type systems have it. There's more to it than that [7]. Haskell and Scala have type classes and implicits as mechanisms for ad-hoc polymorphism, but modular implicits (if implemented) seem to strike a nice balance between readability, flexibility, and transparency.
[1]: https://blog.mads-hartmann.com/ocaml/2015/01/05/gadt-ocaml.h...
[2]: https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/
[3]: https://stackoverflow.com/questions/48092739/what-are-row-ty...
[4]: https://dev.realworldocaml.org/first-class-modules.html
[5]: https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-...
[6]: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
[7]: https://arxiv.org/pdf/1512.01895.pdf
Part of this has to do with the fact that it is not possible (without tricks) to have multiple different typeclass implementations for one type in Haskell (I believe Rust also has this restriction). This language restriction has the tendency to seep into people's way of thinking about monads (and other typeclasses). However, it is not fundamental that a typeclass (or other ad-hoc polymorphism) system has this restriction.
That being said, the language design problem of how to support multiple different typeclass implementations for one type is actually trickier than you'd think. For example, it's easy to fall into the diamond problem if you don't have instance canonicity. If you're interested in how this problem can be solved in practice, check out this lovely paper about Modular Implicits in OCaml [1]. The paper is quite accessible if you have some FP background.
[1] https://arxiv.org/pdf/1512.01895.pdf
As a layman I would describe them as implicits like in current Scala [0] but better (easier to reason about). One thing which they allow is ad-hoc polymorphism like typeclasses.
https://arxiv.org/pdf/1512.01895.pdf
https://old.reddit.com/r/ocaml/comments/4qan0w/modular_type_...
[0] https://scala-lang.org
> No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses.
Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedious to pass around module definitions all the time, which is why they added equality types when the language was originally designed. This is considered an ugly hack though, even by its own creators [0].
Definitely agree that folks should aim for better than type classes, especially due to complications around global instance coherence. One nice solution is modular implicits/instance arguments [1][2]. Tricky thing is to do it without adding…
Read the full comment
too much complexity to the language.
I do wish that there would just be some acknowledgment that it's a hard, but real problem to solve for Elm's point in the design space, rather than just pretending it isn't there. It's ok just to say that you're not spending design capital on it at the moment due to more pressing issues!
[0]: https://github.com/SMLFamily/Successor-ML/issues/18
[1]: https://arxiv.org/abs/1512.01895
[2]: https://www.researchgate.net/profile/Dominique_Devriese/publ...
Gluon recently added implicit arguments with the latest release (see http://marwes.github.io/2018/06/19/gluon-0.8.html). In spirit it is like modular implicits (https://arxiv.org/pdf/1512.01895.pdf). This is really exciting because modular implicits represent a pragmatic balance between the flexibility of ML modules and the convenient overloading of type classes.
Another cool feature of Gluon is modules are basically just records. This is a strict improvement over ML modules in my opinion. (See http://gluon-lang.org/book/modules.html)
Congrats on the recent release!
If by "all constructions wiht HKTs", you mean what can be done with HKTs in Haskell, then I'd say yes. It is well-known that ML modules provide a very advanced level of expressiveness, especially since OCaml's introduction of first-class modules. Also, Scala took this idea further and provides principled recursive first-class modules (which Scala calls dependent object types).
The problem is that modules in ML have a verbose syntax and are clunky to use compared to type classes. OCaml's modular implicits aim to make this better (see https://arxiv.org/abs/1512.01895), taking inspiration from Sala's implicits.
If I'm not mistaken, this release is not the multicore release[0]. Also, if anyone's keen on reading the paper behind modular implicits in OCaml, its a fun read - http://arxiv.org/abs/1512.01895
[0] - https://blogs.janestreet.com/flambda/#comment-39958
If you don't mind reading a paper, there's a paper on it that actually is readable instead of just all whitepapery and overly-theoretical: http://arxiv.org/pdf/1512.01895.pdf
Modules are strictly more powerful than Haskell type classes (at least, more powerful than naive type classes; there are so many extensions that I'm not sure that is still the case). Modular implicits are described here: http://arxiv.org/pdf/1512.01895.pdf. The main problem with modules as typeclasses is that it's pretty painful to use in practice, and modular implicits fix that, giving a solution quite reminiscent of Haskell type classes. I don't know Scala implicits well enough to comment, but the authors feel their version avoids most of the problems in Scala's implicits (they jokingly refer to it as "a more explicit kind of implicit").
(The third edition corrects minor typos and adds 3 chapters synthesized from published papers plus an appendix on maximum entropy distributions.) The monograph investigates the misapplication of conventional statistical techniques to fat tailed distributions and looks for remedies, when possible.
I prove that if markets are weak-form efficient, meaning current prices fully reflect all information available in past prices, then P = NP, meaning every computational problem whose solution can be verified in polynomial time can also be solved in polynomial time.