There seems to be some confusion here ... the error message
that Hugs produces has nothing at all to do with ambiguity.
According to my own calculations, and those of Hugs:
happySpecReduce_1 :: Int -> (a -> a) -> Int -> b -> c
-> [HappyState b ([a] -> d)] -> [a] -> d
And the reduction function in the local definition of happyReduce_1
gets the type:
reduction :: (Fractional a, Functor b) =>
HappyAbsSyn c (b (d,e -> f)) g -> HappyAbsSyn (e -> a) h i
Consequently, happyReduce_1 gets type:
happyReduce_1 :: (Functor a, Fractional b)
=> Int
-> c
-> d
-> [HappyState c ([HappyAbsSyn (e -> b)
(a (f,e -> g))
h
] -> i
)
]
-> [HappyAbsSyn (e -> b) (a (f,e -> g)) h]
-> i
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.
I hope this clarifies the problem.
Mark
