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!
(However, I don't understand the monomorphism restriction either, so the
moderator may want to drop this message!)
Surely as len takes no arguments, the contexts of its two uses are
equivalent, so the two uses should bind to the same evaluation?
[See Section 4.5.5 of the Haskell report, it explains why an example
like the one below is problematic if you haven't got the MR -moderator]
----------
From: simonpj
Sent: 21 July 1998 10:03
To: Olaf Chitil <[EMAIL PROTECTED]>;
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Monomorphism
To: Olaf Chitil <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Monomorphism
From: Simon L Peyton Jones <[EMAIL PROTECTED]>
Olaf suggests
> Hence I suggest that part (b) of rule 1 of the MR should
> be deleted, i.e. simple
> pattern bindings are just treated as function bindings.
That would indeed not fall foul of the ambiguity problem, but
it doesn't deal with the unexpected efficiency problem.
Consider:
f xs = if len > 3 then len else 0
where
len = length xs
You are a first year undergraduate. Quick, how many times is the
length of xs computed?
Correct! Twice! I'm assuming here that we've made the change
to length to give it the sensible type
length :: Num b => [a] -> b
