Original-Via: uk.ac.nsf; Fri, 13 Dec 91 13:53:03 GMT
Original-Sender: [EMAIL PROTECTED]
I think the problem is that Haskell's eager resolution strategy for
overloading is a major design decision that needs to be emphasized
much more in the preface, but the addition to section 4.5.2 fills the
gap somewhat since it at least hints at the resolution strategy
rather than just baldly stating a restriction on contexts.
I think the C-T rule is very relevant here also and should be
emphasized much more. Perhaps by adding a further sentence
that goes something like
Note that by the C-T rule this is safe since the type
constructor [] must have been declared an instance of Eq
already if it is ever to be one.
For this reason a more abstract example instead of one based on Eq
would be preferable since the fact that everything relating to Eq
and [] is already fixed up in the prelude is likely to be confusing
when thinking about the C-T rule.
Satish
P.S. This is in response to Simon's proposal:
Add to the end of para 2 of 4.1.3 the following
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Furthermore, the context c must be of the form given above in
4.1.2; in particular, it may constrain only type variables.
Add to 4.5.2 the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
As mentioned in 4.1.3, the context of a type may constrain
only type variables. Consider, for example, the definition
f xs y = [x] == ys
Its type is given by
f :: Eq a => [a] -> a -> Bool
and not
f :: Eq [a] => [a] -> a -> Bool
Even though the equality is taken at the list type, the
context must be simplified, using instance declaration for @Eq@ on
lists, before generalisation. If no such instance is in scope,
an error is signalled.
