Modular implicits · HackerPapers discussions

Modular implicits — mentioned by nukifw

Wed, 13 Aug 2025 23:14:31 GMT

- 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`.

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by nequo

Fri, 26 Jul 2024 17:16:01 GMT

> 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

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by sgeisenh

Mon, 13 Dec 2021 04:00:26 GMT

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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by lpage

Fri, 06 Aug 2021 05:15:10 GMT

* 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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by Shoop

Fri, 08 Jan 2021 01:09:27 GMT

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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by tutanchamun

Sun, 22 Sep 2019 16:44:01 GMT

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

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by bjz_

Tue, 21 Aug 2018 23:27:20 GMT

> 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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by jdreaver

Fri, 22 Jun 2018 20:19:06 GMT

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!

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by lptk

Mon, 30 Apr 2018 10:09:50 GMT

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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by pauldirac137

Thu, 28 Apr 2016 17:13:37 GMT

This is exactly the problem that modular implicits will solve. See http://arxiv.org/pdf/1512.01895.pdf

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by krat0sprakhar

Wed, 27 Apr 2016 23:11:39 GMT

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

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by ubertaco

Fri, 01 Apr 2016 03:43:12 GMT

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

Paper and discussion history. A mention is not an endorsement.

Modular implicits — mentioned by pauldirac137

Thu, 31 Mar 2016 20:37:55 GMT

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…

Paper and discussion history. A mention is not an endorsement.

Modular implicits — HN submission

Sat, 12 Dec 2015 14:02:21 GMT

Modular implicits for ad-hoc polymorphism in OCaml

1 point; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.