Wed, 1 Mar 2000 21:09:17 +0300 (MSK), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:
> But the instance (dictionary) for Eq [Bool] can be deduced in
> multiple ways! The first is the standard `deriving'. The second
> deduces from the user instance.
> But I have certain wise rules to resolve the choice ...
No: if there is the standard 'deriving', a user instance is illegal.
There is no choice. I say exactly what I mean and expect the compiler
to do exactly what the program means.
The point I am trying to make is that I don't let the compiler choose
the semantics, or choose which of my functions to call (because they
imply semantics). I only let it choose the implementation, and each
possible implementation must give the same result. The beautiful
thing in Haskell is that if there is an ambiguity, the programmer
must resolve it, unless it is in some way explicitly marked as unsafe
and the programmer knows about it. That way there are less surprises
for a programmer - it's annoying when he changes something innocent,
or only adds something, and then other code silently breaks.
> And what the implementors speak of the necessity to add Eq [a] ...
> in one or another situation with overlaps
> - this has to be only one of the possible compilation ways.
> The compiler should not discuss with the user its compiler's
> problems, if they can be solved automatically.
But can they really be solved automatically?
> Let us distinguish between the *unique* meaning of the program and
> various possible compilation techniques.
With overlapping instances there is no unique meaning. (The compiler
does not know whether several user instances yield the same result.)
> I use essentially the overlaps in my CA program. They help a lot.
> And I want them to get into the language standard.
So somebody must design a clear semantics of the language equipped
with overlapping instances, practically implementable and having as
little traps for the programmer as possible (and no traps / harm for
the programmer that does not use them).
I haven't seen such thing yet, and I guess that it is impossible.
> But the existing implementations often force me to write the things
> like (Field a, Ring (ResidueE (Pol a)) =>
> instead of plain (Field a) =>
Because overlapping instances are not quite compatible with Haskell
classes! With the concept, not a particular implementation.
Moreover, I want to avoid the possibility that some controversial
feature would prevent having some another nice feature in the future,
where the first can be done in some way but both are by no means
compatible.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
