[Haskell-cafe] Closed classes

[David Feuer]

It seems *highly* related, and, to my untrained eye, very carefully
considered indeed. Unfortunately, based on the fact that its website has
not updated since 2010, it appears that the entire HASP project has died a
quiet death.

One thing that's not clear to me is whether the instance chain approach
(including explicit failure and backtracking) can interact well with
associated types. My understanding is that backtracking in instance
resolution cannot be allowed to infect unification, on pain of impossibly
bad performance. Thus I imagine there would have to be some restrictions on
the use of associated types in instance and/or class contexts; I don't know
if it would be possible to make that work out cleanly and flexibly.

On Thu, Feb 18, 2016 at 12:34 AM, Eric Seidel <eric at seidel.io> wrote:

> The work on instance chains[1] seems related, but I'm not very familiar
> with it, so it might just be superficial.
>
> [1]: http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf
>
> On Wed, Feb 17, 2016, at 14:21, David Feuer wrote:
> > I was thinking about ~two notions of "closed class" yesterday, and I'm
> > curious if anyone's done any work on either concept. In each case, the
> > class definition is followed by *all* of its instances, and the instances
> > are checked *in order* (rather than based on specificity and
> > OVERLAPS/OVERLAPPABLE pragmas).
> >
> > No backtracking:
> >
> > If the instance head matches, GHC commits to it. Associated types are
> > treated as closed type families, and would work just the same (I don't
> > think any significant extension to the closed type family mechanism would
> > be required). This seems to make a very nice parallel to the usual open
> > classes with open associated types. And it lets you combine overlapping
> > instances with associated types without (I believe) risking type safety.
> >
> > Backtracking:
> >
> > GHC does not commit to the instance until it has satisfied the instance
> > constraints. This lets instance writers offer multiple alternative
> > instance
> > constraints. Associated types would be a good bit trickier. One option
> > would be to require all instances with the same head to share a type/data
> > instance. The other (much more invasive) option would be to allow the
> > instance chosen to guide the type selection, which would push the
> > backtracking into the type checker.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160218/fe78a451/attachment.html>