On 13-Aug-1999, Gerhard Schneider <[EMAIL PROTECTED]> wrote:
> Given
>
> class C a where
> m :: a -> ()
>
> instance C () where
> m() = ()
>
> we observed the following behaviour:
>
> (0) Error with GHC and Hugs:
>
> f = \x -> m x
>
> (1) OK with GHC and Hugs:
>
> f1 x = m x
>
> (2) OK with GHC and Hugs:
>
> f :: C a => a -> ()
> f = \x -> m x
...
> Case (0) produces an ambiguity error. The question is:
>
> - What is the difference between (0) and (1)?
>
> - Why can the type given in (2) not be inferred?
I believe you have run into the infamous "monomorphism restriction".
See section 4.5.5 in the Haskell Report.
According to the conventional wisdom, as reflected in the rules
specified in the Haskell report, the difference between (0) and (1) is
as follows: with (0) the programmer might think that `f' was a constant
which would only be evaluated once, whereas with (1) the programmer knows
that the body of `f1' will be evaluated every time that it is called.
To save the programmer from accidentally writing code which might be
inefficient, Haskell disallows (0). However, if the type declaration
is there explicitly, as in (2), then it is assumed that the programmer
will be aware of the efficiency implications, and so Haskell allows it.
The merits of this restriction have been the subject of quite a bit of
debate. I think there is a reasonably good chance that it may be dropped
in Haskell 2.
> (3) OK with GHC, error with Hugs:
>
> f = \x -> m x
> x = f()
...
> - Is GHC's treatment of (3) a bug?
At first glance it looks a bit that way to me, but
I will leave it for the more knowledgable Haskell experts
to give you a definitive answer on that one.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
