On Mon, Apr 16, 2012 at 10:48 AM, Sandro Magi <[email protected]>wrote:
> I think this can be refined further. Typed multiple dispatch languages
> force overloads to form a semi-lattice [1], so:
>
> instance TC('a, 'b) { ... }
> instance TC('a, int) {...}
> instance TC(int, 'a) {...}
>
> Is inherently ambiguous, and would require a module importing both to
> also have the following instance in scope:
>
> instance TC(int, int) {...}
>
That's a fairly large pain in the butt. In my proposal, it is *permitted* to
provide TC(int, int), but it is not *required*. The situation is very rare,
and it is usually true that it doesn't actually matter which variant you
pick.
> "Latest match wins" might be ok if the *exact* same overload is
> redefined, although I'm a little wary of that.
>
Definitely not. It is (and must be) an error if the exact same overload is
redefined.
>
> Another proposal to solve overlapping instances is "instance chains"
> [2]. I thought I had mentioned this work on the list before, but a quick
> search didn't turn anything up.
The instance chains approach is interesting. It's morally similar to
typecase, which is somewhat thought provoking. I concur that there are some
nicely compelling use cases for them.
The problem is that they don't solve the general problem. Instance chains
require that all of the alternatives be stated in a single place. This
fully resolves the resolution ordering problem, but it has the effect of
rendering the type class partially closed. By introducing a resolution
contour, I think we can get the same effect without introducing the
"partially closed" consequence.
My original intention was that instance selection within a resolution
contour would be done by the following rules:
- Prefer the "closest" match, where "closets" means the one requiring
the smallest number of type variable concretizations
- Where the closes match is ambiguous, take the nearest (i.e. the last
in the contour) match
This can certainly be extended to incorporate the chaining idea if that
proves to be motivated. The intuition is that chaining occurs at *open* rather
than at instance declaration:
open TC(char, 'a)
else TC('a, char)
else TC('a, 'a)
The ability to perform ordered open is orthogonal to the relevance and
importance of closed classes.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev