[Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
anthony_clayden at clear.net.nz
Fri Jun 2 07:22:42 UTC 2017
> 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
And looking at Garrett's later 'Variations on Variants'
(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
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
More information about the Haskell-Cafe