Implict parameters and monomorphism

[Andreas Rossberg]

John Hughes wrote:
> 
> I think it's important to have a simple model of how many
> times expressions are evaluated. Function bodies are clearly
> evaluated many times, once for each call, but non-function
> bindings should be evaluated at most once to respect
> call-by-need semantics.

Maybe I misinterpret the Haskell Report but I thought it does not even
demand call-by-need evaluation (it only speaks of non-strict semantics).
So why have a special rule in the language definition to support
something cbn-ish for this particular case? As long as the Report does
not specify any execution model the MR looks rather arbitrary to me.

> Breaking the monomorphism restriction in ANY case makes both
> space and time cost of evaluation unpredictable, and brittle
> when program changes elsewhere introduce or remove an implicit
> parameter. It isn't good enough to say `the chances are' that
> a program has, for example, linear time and constant space
> complexity: the programmer should be able to convince himself
> of such properties.

Why isn't it good enough if the compilers give warnings then? The Report
could even require it. To me it seems overly restrictive to rule out
perfectly correct programs for the sole reason of potentially surprising
space/time behaviour. After all it is not forbidden to write Haskell
programs with obscure space leaks.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids.
 If Pac Man affected us as kids, we would all be running around in
 darkened rooms, munching pills, and listening to repetitive music."