To my
>> [..]
>> How the hacker uses them? One simply takes (+) from Additive,
>> (*) from Multiplicative, dimRem from EuclideanRing
>> - instead of Num, Integral of old Haskell-98.
>> When one wants the instance for the type T with, say, (*),
>> one needs to declare for it
>> instance Set T -- skip implementation !
>> instance Multiplicative T where (*) = ...
Fergus Henderson <[EMAIL PROTECTED]> writes on 6 May 2000
> Personally I think it is bad that Haskell allows this.
> The Haskell report says the following:
| If no binding is given for some class method then the corresponding
| default class method in the class declaration is used (if present);
| if such a default does not exist then the class method of this
| instance is bound to undefined and no compile-time error results.
> But I think it would be better if the last two lines were replaced
> with
>
> | if such a default does not exist then a compile-time error results.
>
> The existence of this loop-hole compromises Haskell's static type
> safety.
If this happens, there will appear more definitions in the
application programs like
instance Foo (C a) where foo = dummy_of_some_kind
-- or maybe = error "..."
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.
Haskell can do nothing about this and should not do.
To prohibit this means to prohibit the programming at all.
On this subject, Bart Demoen <[EMAIL PROTECTED]> writes
>> I am quite happy with not getting a compile-time error for
>> non-implemented class methods, as long as I get a compile-time
>> error when I try to use a non-implemented class method.
Maybe, it is the best approach?
Skiping the method definition is compiled but the compilation of
the usage of this definition does not pass.
And I think, this very approach does not contradict basAlgPropos.
>> Also one writes, for example, zero x
>> instead of zero `asTypeOf` x.
> The latter is clearer. This change reduces program readability, IMHO.
> I also agree with Marcin 'Qrczak' Kowalczyk's arguments on this issue.
The expression zero `asTypeOf` x
still is, *formally*, not a constant, it depends on x and means
certain map applied to x.
The same is zero x
Also zero x is shorter.
Finally, with class Foo a where cardinality :: Int
your approach is impossible.
We are still forced to introduce a sample (dummy) argument
class Foo a where cardinality :: a -> Int
>> Is simplicity possible?
>> -----------------------
>> Some people say here, that this is impossible, that the compilation
>> errors become the run-time ones ...
>> I do not see, so far, in what way these matters may occur serious.
>> For the critics, it is a good point to provide some schematic
>> examples.
> OK. Consider the following scenario. Alfred defines a type `T'
> and writes such a vacuous instance declaration for `Set T'.
> This is part of a large library package that Alfred has written.
> Meanwhile, Betty has written another library package that provides
> functions on `set a'. Charles writes a program using both Alfred's
> and Betty's libraries. Being pressed for time (aren't we all?),
> Charles does not test his program very thoroughly. Instead, since
> his program type-checks, and it's late Friday evening
> [..]
Rather long thing. The impression is that the trouble is in
"late Friday evening" and such things, that may happen with
*everything*, independently on whether this thing is based on
basAlgPropos or it is just in Haskell-98. I try to understand it:
Alfred.hs [or .o ?] :
type T a = ...
instance Set (T a) where baseSet = vacuous...
...
Betty.hs [.o]: f :: Set a => a -> T a ...
...
Charles.hs [.o]: import Alfred
import Betty ...
...
What you are saying is that setting things like
baseSet = error "dummy_baseSet"
for T a
creates the problems because Charles may like to exploit
essentially the result of baseSet on say T Bool.
Right?
This critic looks strange: searching for problems where there are
not any.
Alfred defined *his* user type T and *his* Set instance for it.
And Charles dislikes this instance.
Why basAlgPropos is guilty? The same is with any other libraries.
When a person writes a program module A (f) ... for others and puts
f 0 = error "",
of course, how could others pretend to use this program, if they
need f 0 = 1 ?
It is a matter of manual on `A' to explain what the user should
expect of it, and what it fits for.
For example, writing the above program Alfred.hs under
basAlgPropos, a good hacker has to put in documentation
"
The program Alfred was compiled without -fadvancedAlgebra:
the standard advanced algebra operations are put dummy.
"
- otherwise, the users would still discover soon that Alfred does
not support these advanced things!
Again:
it is very natural for the user program to put for some user types
T some operation instances of some standard class C as the
"really" designed ones, and do not care of other operations of C
for T.
This "not-caring" may be expressed either in skipping the
operation definition or in defining it dummy -
basAlgPropos can, probably, accommodate both approaches.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
