Matthew Ryan

This is now ready for review. Old version is [here](https://github.com/mrmr1993/ocaml/tree/feature/modular-explicits-types-2). In this version, every type is associated with an `(Ident.t * Ident.t) list`, which is used to help resolve paths...

@trefis I've put up a branch [here](https://github.com/mrmr1993/ocaml/tree/feature/modular-explicits-expressions-3) to add support for expressions. Would it be better to keep this PR as the type implementation only, or should I pull those...

Rebased this (and the [expressions branch](https://github.com/mrmr1993/ocaml/tree/feature/modular-explicits-expressions-3) that builds upon it) onto trunk.

Updated to fix the error message issue mentioned above, and to fix the CI failure.

Rebased onto latest trunk. The branch introducing support for expressions is in PR mrmr1993/ocaml#1.

@trefis to update, I have been working on an implementation of implicits built upon this PR. This is currently split into several PRs on my fork: * mrmr1993/ocaml#1 contains the...

> maybe we could have something like the following? > > ```ocaml > let show: type a. {S: Show with type t = a} -> a t -> string =...

@trefis I've rebased this and pulled in the changes from mrmr1993/ocaml#1, as per our email exchange.

Updated to rebase this onto trunk. This also adds an improvement to the identifier printing algorithm that was highlighted by some upstream changes to printing.

> Could these configurations be handled by dune using functionalities such as virtual libraries and/or `enabled_if` attributes ? That should get rid of most of the uses of optcomp, yes....