<div dir="ltr">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.<br><br>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 12:34 AM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The work on instance chains[1] seems related, but I'm not very familiar<br>
with it, so it might just be superficial.<br>
<br>
[1]: <a href="http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf" rel="noreferrer" target="_blank">http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 17, 2016, at 14:21, David Feuer wrote:<br>
> I was thinking about ~two notions of "closed class" yesterday, and I'm<br>
> curious if anyone's done any work on either concept. In each case, the<br>
> class definition is followed by *all* of its instances, and the instances<br>
> are checked *in order* (rather than based on specificity and<br>
> OVERLAPS/OVERLAPPABLE pragmas).<br>
><br>
> No backtracking:<br>
><br>
> If the instance head matches, GHC commits to it. Associated types are<br>
> treated as closed type families, and would work just the same (I don't<br>
> think any significant extension to the closed type family mechanism would<br>
> be required). This seems to make a very nice parallel to the usual open<br>
> classes with open associated types. And it lets you combine overlapping<br>
> instances with associated types without (I believe) risking type safety.<br>
><br>
> Backtracking:<br>
><br>
> GHC does not commit to the instance until it has satisfied the instance<br>
> constraints. This lets instance writers offer multiple alternative<br>
> instance<br>
> constraints. Associated types would be a good bit trickier. One option<br>
> would be to require all instances with the same head to share a type/data<br>
> instance. The other (much more invasive) option would be to allow the<br>
> instance chosen to guide the type selection, which would push the<br>
> backtracking into the type checker.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>