[Haskell-cafe] [ghc-proposals/cafe] Partially applied type families

[Anthony Clayden]

> On Fri Jun 2 02:32:39 UTC 2017, Richard Eisenberg wrote:

> 
> > On May 31, 2017, at 12:31 AM, Anthony Clayden wrote: 
>
> >> You could always view
> >> 
> >>> instance TypeError ... => C Int Bool
> >> 
> >> as sugar for
> >> 
> >>> instance C Int Bool fails
> > 
> > Yes I understand that.
> > But no I don't want any instance.
> > (Sugar on rotten fruit doesn't hide the smell.)
> 
> I hereby pronounce
> 
> > instance TypeError ... => C Int Bool
> 
> as "not an instance". ...

Hmm. I'd be interested how you're going to stop
the compiler matching some usage site to it.

> In other words, I'm not sure what
> you're getting at here other than concrete syntax.
> How does not having an instance differ
> than the TypeError solution? 

Good question. I've been struggling to explain it.
Re-reading the Instance Chains paper has clarified the issue
for me.
And looking at Garrett's later 'Variations on Variants'
paper.
(Clarified, because that's a non-solution.)

It's the Expression Problem:
Once I have a catch-all instance
(even if it has an impossible-to-fulfill constraint)
the compiler is committed to selecting that instance.

I can't introduce a new data type
and new instance for it,
because it'll overlap the catch-all instance.

IIUC, Instance Chain's 'fail' is more powerful,
it triggers back-tracking to look for another instance
that doesn't fail.
But we don't want to introduce backtracking
into Haskell search for instances.

Nevertheless, I can only write one Instance Chain
per class. So I can't (say in another module)
introduce a new datatype with instances.

Sometimes closed/chained instances
are the right solution.
(That's the case for HList, for example.
 But even there I'm not convinced.
 I might want as well as HNil, HCons,
 a constructor with explicit type-labelling.)
But sometimes closed instances are not right.

I would say that where closed instances are needed,
you can still achieve that with a 'catch-all' stand-alone
instance,
suitably guarded, of course.

So I disagree with Garrett:
not only do Instance Chains fail to solve
the expression problem, they actually exacerbate it.
(Same for Closed Type Families,
 or Closed Class Instances.)

> > OK. Perhaps you're seeing something I can't.
> > To adapt your example from a parallel message, suppose:
> > <snip>
> 
> What you're getting at here is that there may be
> interesting interplay between instance guards and
> OverlappingInstances. Indeed. This would have to be worked
> out (or left as an open question) in the proposal.
> 
> Regardless, I think that hashing out this level of detail
> here is the wrong place. ...

OK, fair enough.

> Put it in the proposal! That way, the ensuing
> debate involves more of the community and
> persists better.
> 

Oh! that I had "Deserts of vast eternity"
to write the thing.
As it is, it's easier to tackle as bite-size pieces on the
forum.

AntC