Indeed. With functors one uses the path equality check as a way to enforce
coherence, with a phantom type you can let people build their own phantom
paths and use them to mark type (in)compatibility. This is slightly less
safe (in the sense that users can always break that promise if they want to
by behaving badly -- but I think this is fine), but also easier to use
(than the module language) and more flexible in some cases.

On Tue, Sep 29, 2015 at 4:52 PM, Yaron Minsky <yminsky@janestreet.com>
wrote:

> Core_kernel's maps and sets solve this problem, and address Gabriel's
> concern as well, by providing type witnesses that distinguish maps
> built with different comparators.  There's an introduction to the use
> of these modules here:
>
> <https://realworldocaml.org/v1/en/html/maps-and-hash-tables.html>
>
> and you can see the current APIs here:
>
> <https://github.com/janestreet/core_kernel/blob/master/src/core_map.mli>
>
> Sets are handled similarly.For sure, better inlining (as is coming in
> Flambda!) can make this approach better.
>
> y
>
> On Tue, Sep 29, 2015 at 9:56 AM, Jesper Louis Andersen
> <jesper.louis.andersen@gmail.com> wrote:
> >
> > On Tue, Sep 29, 2015 at 2:58 PM, Gabriel Scherer <
> gabriel.scherer@gmail.com>
> > wrote:
> >>
> >> Note that the polymorphic sets (or maps) are less statically-safe than
> >> their functorized counterpart, because they are parametrized over their
> >> comparison function at creation time
> >
> >
> > The only point in time I've had troubles is when you have a map where its
> > values and keys range over a type that can recursively contain that map
> of
> > the same type. This required a polymorphic compare (from Core) to pull
> off.
> >
> >
> > --
> > J.
>