To my
>> Indeed, I had met a couple of times in practice that forgetting of
>> import <CertainModule> ...
>> may lead to successful compilation and the un-desired change of
>> computation result at the run-time!
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes on 5 Feb 2000
> I think it's hard to avoid with overlapping instances. The semantics of
> overlapping instances are simply not nice: they say that a definition
> applies *unless* the type has certain properties. This is strange in
> itself, and I would accept it only when in such case there is another
> definition which gives the same result more efficiently (in such case
> forgotten imports won't cause errors, only inefficiencies).
>
> If the result was different after adding imports, it's a symptom of an
> error in the design of particular classes, or maybe other deficiencies
> of the class mechanism itself. IMHO overlapping instances don't fit
> well the current model.
This is not the guilt of overlaps, only the choice of the programmer.
Why should the programmer write anything senseless or counter-
intuitive?
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.
And the special instance for a = Integer knows this and gives Fin 5.
Omitting some import causes less definite result.
The effect is similar to what you mention
> definition which gives the same result more efficiently
Both Fin 5 and UnknownValue are correct.
But the former is more precise and is returned in special case.
> The semantics of overlapping instances are simply not nice: they
> say that a definition applies *unless* the type has certain
> properties. This is strange in itself, and I would accept it only
> when in such case there is another definition which gives the
> same result more efficiently
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
".
This is the usual approach in scientific computation.
> Adding a type to a class should not restrict what we can do with
> values of that type, or cause previously working function to fail,
> or to change its meaning.
Probably, overlapping instances, as they are recently presented,
meet this requirement.
> If a type could have various instances of a class,
> probably the implementation should be passed explicitly instead of
> through a class - classes are for cases when there is only one natural
> implementation for a type.
Sounds rather dim for me.
What does this mean "implementation passed explicitly",
"implementation passed through a class" ?
> classes are for cases when there is only one natural
> implementation for a type.
Why not allow generic and specific implementations?
To my mind, this does not raise obstacles for classes.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
