Except that this isn't actually allowed because happyReduce_1 appears
in a restricted binding group, and hence can't have any context in its
type. So, at this point, Hugs complains. GHC, I assume, just assigns
hugsReduce_1 a monomorphic type, only to find at some later point that
the list instance of Functor (and only that instance) are required to
make things type check.
Hugs is perhaps too eager in complaining, but it can't assign anything
other than a fully polymorphic type to top-level terms, so it doesn't
really have much choice. For now, the simplest fix would seem to be to
use a non-overloaded map function.
... or to give an argument to happyReduce_1, which would
mean it wasn't restricted any more...
I think that's an accurate diagnosis. The interesting questions are:
a) which compiler is implementing the language definition?
b) is the langauge definition "right"?
A quick look at 4.5.5 of the 1.4 report suggests that GHC
is implementing the language definition and Hugs is not.
The monomorphism restriction simply says you can't generalise
that type variable. The report gives examples that make
it clear that you are expected to be able to use the monomorphic
definition at any one type in the module.
Whether this "monomorphism restriction" is the "right" language spec is hotly
debated. But it seems fine to me.
Simon
