Magic classes for Overloaded Record Fields, overlaps, FunDeps

[AntC]

> Simon Peyton Jones <simonpj <at> microsoft.com> writes:
> 

Hi Simon, I don't think there's an 'issue' in the sense fundeps 
can achieve something that type-families can't (or v.v.).
It's more about elegance and ergonomics of the code to achieve it.
(I'll try to avoid a question of judgment shading into a matter of taste ;-)

> |  > I have been vacillating between type families and fundeps for the ORF
> |  > classes. I hadn't fully appreciated this point about overlap, but I
> |  > think it is a reason to prefer fundeps, which is the direction in
> |  > which I'm leaning. I'd be grateful for feedback on this issue though!
> ...
> 
> |  The difficulty remains that as soon as you want overlaps in such a way
> |  that takes you to FunDeps, it's very difficult to 'mix modes' with type
> |  families.
> 
> Can one give a standalone explanation of the fundep/type-family/overlap
> issue here? 
> Or is it explained on a wiki page?
> 

Neither is it specifically about the Overloaded Record Fields design,
nor anonymous records -- it's just that you need a meaty application
like those to demonstrate the subtleties.

I've taken some time to review what's explained where.
I think most of it has come up before, scattered various places.
I see 4 inter-related pieces.
I'll volunteer to write these up, if somebody would like to tell me where.

1. ORF has chosen the `Has` class to be implemented using FunDeps,
    rather than type families.
    The motivation (for 'option 1') is documented on the wiki,
    pointing to the original design (with which you were involved). 
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Design

    Choosing FunDeps is right if we move on to anonymous records,
    which are bound to face some egregious overlaps, so...

2. Adam's point (and example) about overlap of instances wrt 
    anonymous records, has been 'in the wind' before -- e.g. comment here
https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-
families/#comment-152
     Detecting the unwanted ambiguity of instance satisfaction
     is discussed in the HList paper's `Lacks` constraint.

3. There's a clumsiness in type families faced with such examples.
    Really you want to put an equation in a closed type family
    to 'trap' or guard against the ambiguity.
    But in effect say "treat this as an error, not a proper instance".
    So the Instance Chain work (for example) has a 'fails' outcome.

4. When you've decided to implement some piece using FunDeps,
    It works OK to delegate some of the type-level calculations to
    (possibly closed) type families, per Adam's response to my q on this thread.
    But v.v. if you have some piece using type families,
    and then want to delegate to FunDeps because of nasty overlaps;
    that tends to get awkward.
    It's better than it was with the first releases of type families.


AntC