Sun, 6 Feb 2000 11:29:28 +0300 (MSK), S.D.Mechveliani <[EMAIL PROTECTED]> pisze:
> In my case, it was not so bad. The results were different in a weaker
> sense. It was like this:
> card z5 --> Fin 5
> "integers modulo 5 has finite cardinality 5"
>
> Omitting certain import caused card z5 --> UnknownValue.
> This was due to that the generic instance for
> Euclidean a => Residue a
> does not *know* how to compute certain cardinality, and so, puts it
> UnknownValue.
I don't know your class hierarchy (I've tried to study it some time ago
but it was too complex), but maybe the place where the cardinality is
computed is wrong, too high, should be in a separate class, or whatever.
If it does not know, it should not specify it.
Probably the system of Haskell classes is not well suited for instances
like "if it is ever X, it's certainly Z as well and the implementation
of Z depends on the implementation of X, but generally X is not needed
for Z". Standard Haskell does not allow such things and not without
a reason. There are ambiguities if something was defined as "if it's
X then it's Z, if it's Y then it's Z, it's X, it's Y" - but *how*
it should be Z - basing on X or Y?
I feel such hierarchies unclear and would avoid them. Even if it
requires to specify many instances of "parent" classes for each type
instead of having instances defined in a generic way further above
(at most they could be "instance Z T where z = makeZfromX"), as in
gtk+hs. Or it requires to represent overloaded instances as first class
values instead of Haskell classes, and domains as values instead of
types (something like Hugs' dynamic binding should help here to make
syntax more pleasant). Both solutions cause less technical troubles
than relying on -fallow-undecidable-instances, even if they are a
bit less convenient to use.
> I do not agree.
> The feature is very natural:
> "if type is supplied with extended attributes
> (properties,instances) apply this clever specific method,
> otherwise, apply the generic one
> ".
I do not agree. If a generic implementation does not work for this
case, either it is not a special case of the generic case, or the
generic implementation is wrong itself. A generic implementation
should work correctly for all special cases - that's why it is placed
in a generic place and called generic. If an artificial implementation
which don't always work must be placed in a generic place because it
is tied to implementations of other things, it should be separated,
or possibly the other things should not be implemented in a generic
way as well.
Maybe it would be good to allow specifying such things in some way,
but it would require some more substantial changes in the language.
> What does this mean "implementation passed explicitly",
> "implementation passed through a class" ?
Like the difference between sortBy and sort.
> > classes are for cases when there is only one natural
> > implementation for a type.
>
> Why not allow generic and specific implementations?
Because generic implementations are more easily ambiguous, as I tried
to show above.
--
__("< 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-
