"Brian Smith" <[EMAIL PROTECTED]> writes:
> > http://haskell.org/haskellwiki/GHC/StandAloneDeriving
>
> Basically, the syntax
> for instances and derived instances would be identical, but derived
> instances would just omit the "where" clause, while non-derived instances
> would need the "where" clause.
This is a really _bad_ idea for readability. In a year's time, when
this discussion is forgotten, who would be able to tell at a glance the
deep and real semantic difference between the following two instance
decls?
instance Num (Bar z) where
and
instance Num (Bar z)
The former declares that _no_ methods are defined (except for defaults),
and the latter, with your proposal, that _all_ methods are defined. The
real killer is that both of these decls are already valid in Haskell'98,
but they mean the _same_ thing (the former, if you were wondering).
This is a sure recipe for introducing new and subtle bugs into existing
bug-free programs.
Malcolm, thank you for pointing that out. To be honest, I had not read this sentence of the report (section 4.3.2 of http://haskell.org/onlinereport/decls.html ):
"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."
Personally, I think that the part after the semicolon is the part that leads to subtle bugs, not Brian H's proposal. Why is this not considered a compile-time error? There was a previous mention of it on the list [1] but there was no explanation given. I think it would be better if the report stated this instead:
"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 a compile-time error results."
[1] http://www.haskell.org/pipermail/haskell/2003-May/011899.html
- Brian
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
