> 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
