overlapping instances and constraints
claus.reinke at talk21.com
Sun Feb 26 11:27:58 EST 2006
the point about overlapping instances is that they shouldn't,
so we are looking for ways to resolve what looks like overlaps
unambiguously, so that there are no overlapping instances left.
we don't want overlapping instances in the language definition,
but we do want more expressive means of defining non-
1. resolving overlaps in favour of the most specific declaration
does so, so why is that approach slated as "adopt: probably no"?
2. FDs can help to make types in instance declarations more
specific, thus avoiding some overlaps or at least helping the
"best-match" to resolve overlaps. defaults resolve some of
the simplest overlaps (which instance of Num did you mean?),
but not others, because their overloading is not expressed in
terms of classes (which empty list did you mean?).
3. in this context, could someone please remind me what exactly
is the reason that class constraints in instance declarations are
ignored when deciding whether two instances overlap?
we have two worlds to consider, the unconstrained world of
semi-decidable type class programming, and the restricted
world which guarantees termination of type class inference.
in the first world, it seems there is no reason not to look at
the constraints, because there are no termination guarantees
anyway. and in the second world, it seems there is no reason
not to look at the constraints, because we know that doing
so will terminate nicely, thank you.
so why are some instance declarations still rejected as
overlapping even if their constraints clearly say they don't?
More information about the Haskell-prime