On 08-Mar-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> There has been a great deal of mail about overlapping
> instances. I confess that I have read little of it.
> But I am interested in it.
>
> Would someone like to write a summary of
> what the issues are
> what they disagree about
> what people agree about
> (as briefly as poss)?
Briefly, the issues are:
(a) whether overlapping instance declarations should be allowed
(b) if they are allowed, what the semantics should be
(c) if they are allowed, what contexts should be required in
function signatures
(d) whether those legality rules and semantics are feasible,
i.e. whether they can be implemented without significantly reducing
efficiency or causing significant problems for separate compilation
---------------------------------------------------------------
(a) whether overlapping instance declarations should be allowed
---------------------------------------------------------------
There is certainly no agreement here ;-)
-----------------------------------------------------
(b) if they are allowed, what the semantics should be
-----------------------------------------------------
There seem to be two main possibilities:
(b1) the semantics of a method call is determined by
the set of instance declarations occurring anywhere
in the program
(b2) the semantics of a method call is determined by
the set of instance declarations which are in scope
at the point of that call
It seems to be generally agreed that (b1) is not really
feasible, and that even if it was, it might not be desirable.
So most of the discussion has centered on (b2).
[However, I think this may not have been clear to some of the
participants... some of the arguments against the proposed
extension (see below) seem to have been assuming (b1), even though
the main proponents of the extension were assuming (b2).]
------------------------------------------------------------
(c) if they are allowed, what contexts should be required in
function signatures
------------------------------------------------------------
Much of the discussion has focused on this more specific question:
presuming that overlapping instance declarations are allowed, should it
be legal for a function to call a method with a parameter whose type
might match an overlapping instance declaration that is not included
in the context part of the function's type declaration?
(c1) no
(c2) yes
Well, the above statement of the question is not very precise,
and is quite probably wrong. But hopefully an example will
make it clearer.
instance Eq (Maybe String) where ...
f:: Eq a => [a] -> [a]
f (x1:x2:xs) = if Just x1 == Just x2 then xs else []
Hugs and the most recent CVS version of ghc both choose option (c1) and
disallow this example, for reasons that Jeff Lewis explained:
| In the scope of the `instance Eq (Maybe String)', the
| signature is too general. Built in to the signature is the assumption that `Eq
|(Maybe
| a)' can be reduced to `Eq a'. This is fine when there's no overlapping. However,
|with
| the overlap in scope, it is not correct to perform the reduction, because it is too
| early to commit to the more general reduction.
If you choose (c2), you then have to decide what the semantics for
these constructs should be:
(c21) The semantics are the same as if the constraint had been
mentioned in the signature
(c22) The semantics are something different
Older versions of ghc chose (c22), but there seems to be agreement
that this was a bug. S.D.Mechveliani proposed (c21).
---------------------------------------------------------------
(d) whether those semantics are feasible, i.e. whether they can
be implemented without significantly reducing efficiency
or causing significant problems for separate compilation
---------------------------------------------------------------
It seems fairly clear that (b2) (c1) is feasible, since that is
apparently implemented in Hugs and the latest CVS version of ghc.
There is no agreement regarding feasibility of (c21). It's not clear
whether S.D.Mechveliani's suggestion on how to implement it would work
in the context of constructor classes, existential types, first-class
polymorphism, and other more exotic language features.
I also pointed out that S.D.Mechveliani's suggestion on how to implement
it would cause some problems for separate compilation and stable binary
interfaces.
Hope this helps,
Fergus.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
