CC: [EMAIL PROTECTED]
Yes, I think I understand this. The two contexts of len *aren't* the
same, are they?
Actually, in the circumstances I think that this is correct behaviour!!!
Now, how do we fix it? Can we use type signatures to help us out here?
We know that
f :: (Num c) => [a] -> c
so in this context I'd like to say that len :: c (and rely on an implicit
fromInteger when comparing against 3).
Let me mangle the syntax and write:
(Num c) =>
f :: [a] -> c
f xs = if len > fromInteger 3 then len else 0 where
len :: c
len = length xs
I've now added the (Num c) context to the entire declaration of f, so I
can pin the type of len down tightly enough. I take it that this is the
purpose of the monomorphism restriction (I haven't had time to go and
read section 4.5.5 yet).
Is there any way to express what I've just tried to write above in
Haskell as is or proposed?
----------
From: simonpj
Sent: 21 July 1998 13:51
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Monomorphism
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Monomorphism
From: Simon L Peyton Jones <[EMAIL PROTECTED]>
>
> I'm going to ask a very stupid question.
>
> Why on earth is len computed twice in this example? I really don't
> understand this!
I have to confess that I mischievously hoped that someone
would say this: it demonstates the point nicely that
lifting the monomorphism restriction would cause at least
some people to be surprised.
Let me add the type signatures [I'm a bit puzzled why length used
to have type Integral b => ... but that's a side issue.]
length :: forall a b. Num b => [a] -> b
f :: forall a c. Num c => [a] -> c
f xs = if len > (3::Integer) then len else 0
where
len :: forall d. Num d => d
len = length xs
The first use of len returns an Integer, so we must compute
the length at type Integer.
The second use of len returns a value of type c, so we must
compute length at type c. (Someone *might* call f wanting an Integer
back, they might not.)
And there you have it.
Simon
