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