On 06-May-2000, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
> 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 "..."
That would be a good thing. It would make the original
programmer and anyone else reading the code more aware
of the danger that such incomplete instance declarations
constitute.
> 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.
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.
> 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?
As Marcin 'Qrczak' Kowalczyk, this approach is in general not
possible.
> >> 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.
`asTypeOf` is effectively a builtin language construct that just
happens to be implemented as a function in the standard Prelude
(because it can be). It is even mentioned explicitly in the
main part of the Haskell report (specifically in 4.3.4), not just in
the part describing the Prelude. Anyone who is truly familiar with
Haskell will know exactly what it does.
On the other hand, `zero' and the other functions that take
unnecessary dummy arguments in your proposal do not have the
same status.
> The same is zero x
> Also zero x is shorter.
Shorter does not imply more readable.
> 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
Dummy arguments are sometimes needed.
But the less often they are needed, the better, IMHO.
Incidentally, this is an area where Mercury is more expressive
than Haskell. In Mercury, dummy arguments are still needed sometimes.
But using Mercury's mode system, you can express in the function's
declaration the fact that it depends only on the argument's type, not
on its value, by using the mode `unused' rather than `in':
:- typeclass foo(A) where [
func cardinality(A::unused) = (int::out)
].
The compiler's static checking will enforce this mode declaration;
it would be a compile-time error to define an instance of this
typeclass for which the cardinality function examined the value
of its argument.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
