To my
>> Because it is wrong for the standard classes to pretend for *all*
>> their operations to have a real sense in *all* the user instances.
>> The user may know better one's situation, one may rely on the
>> standard operation op1 and ignore another standard op2, having
>> some replacement for it, maybe, in other, user class, or maybe, not
>> exploiting it at all.
Fergus Henderson <[EMAIL PROTECTED]> writes on 7 May 2000
> The programmer is free to do so, but doing so is risky, and
> so if that is really what they want, they should have to write
> it out explicitly, so that they and future maintainers will
> remain aware of the risk.
Most part of the programming practice (in "scientific" programs) is
risky in principle. This is due to the extreme algorithmic
complexity of many things that might need to be checked for the
program correctness.
Generally, do not hope that just the type checker may fix 1% of
the in-correctness risk. Simplest example.
One programs module M ...
instance Ord T ...
and applies sort xs :: [T]
After the compilation passed and examples show correct results,
one says: "and the type checker verified the correctness of M".
And it had verified maybe 1% of its correctness.
Because if (<) on T occurs non-transitive ... not a good ordering
at all ...
Considering the possible basAlgPropos approach with
-fadvancedAlgebra and with the dummy methods in the instances
Fergus tries to show the example of its danger:
> [..] Alfred defines a type `T'
> and writes such a vacuous instance declaration for `Set T'.
> [..]
After further explanations, and trying to promote the
-fadvancedAlgebra approach, I rearrange it
(for myself to understand - sorry):
Betty.hs [.o]: import StandardProposed (...and Set(..) too)
f :: Set a => a -> Int
...
Alfred.hs [.o]: type T a = T ...
instance Additive (T a) where
(T x)+(T y) = T (x+y)
Charles.hs [.o]: import Alfred
import Betty
foo :: Alfred.T -> ...
foo x = ... (Betty.f x) ...
Betty wants to exploit the result of StandardProposed.Set.basetSet
essentially, and polymorphicaly - in f :: Set a => ...
Betty does not import Alfred nor Charles.
Charles applies Betty.f x for x :: Alfred.T
Alfred defines Additive for T.
`Additive' needs a super-instance of Set.
Alfred knows that StandardProposed may have fancy superclasses
for Additive. But he only needs this (+) for (T x) and being a
hacker, does not care for the advanced superclasses.
He does not even recall the names of these superclasses. He only
skips the compilation key -fadvancedAlgebra.
The compiler sets automatically the dummies for instance Set T
and for a couple of such instances.
Charles applies Betty.f x for x :: Alfred.T and gets an error.
Maybe, according to the suggestion by
Bart Demoen <[EMAIL PROTECTED]>,
the error has to be the compile-time.
Because assume that in the dummies baseSet is skipped for T.
But here, this is not crucial, let it be even a run-time error.
Who is guilty?
--------------
Betty and basAlgPropos are innocent.
Alfred should have declared in manual "not for -fadvancedAlgebra"
- otherwise, why skipped the key, why allowed dummies?
Also Charles applies f for Alfred.T and sees f :: Set a => ...
Of course, he should ask himself, what Alfred might put for
Set T ... ?
Even without more docs than the interface Betty.f :: Set a=> ...,
after getting the error, Charles discovers simply that
Betty.f needs more than Alfred.T provide.
No. People, really, there is no problem here.
This is on the old version of Alfred-Betty-Charles but can (?)
also refer to the above corrected version with `Additive':
> But, suppose Alfred does document his code like this.
> Then how is Charles to know whether passing Alfred.T to Betty.f
> will be safe?
> Perhaps Charles reads Betty's documentation. Now, some of the
> time Betty will simply not have documented whether her library
> depends on the standard advanced algebra operations. In that
> case, if Charles is being cautious, then he cannot use Betty's
> library at all.
> [..]
Charles sees Betty.f :: Set a => ...
As Betty appeals to `Set' explicitly, it is all under
-fadvancedAlgebra.
Also assume the compiler says explicitly that baseSet is skipped
while needed (Demoen's suggestion). And even documentation is not
needed in this case.
These examples sound for me like
"suppose X had not written the program and Y wants to use it, and
Z complains that basAlgPropos does not help here".
Find some *real* objections - maybe they exist?
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
