Implict parameters and monomorphism

[John Hughes]

	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.

Well, the Haskell Report may not require call-by-need semantics, but it
permits it at least. Without the MR that would not be the case: some
programs would *require* call-by-name. Actually I would prefer the report
to be much more explicit about both sharing and evaluation order, to enable 
compiler-independent reasoning about time and space behaviour. As it stands,
compilers do in fact implement call-by-need, and so one can in practice
reason fairly safely about time behaviour, but they vary in the choice of
evaluation order, which makes space leaks come and go on different compilers.

In any case, I don't buy the argument that because reasoning about costs is
already problematic in Haskell, it doesn't matter if we make it even harder...!

	> 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.

I have no faith in compiler warnings. For one thing, they're irritating. For
another, you don't see them when it matters -- when you *read* the code.
I'd far rather explicitly distinguish call-by-name and call-by-value in the
source code (and made a suggestion along these lines some time ago), so that
the semantics is visible to all.

Of course, we can't forbid the programmer to write inefficient programs. But
we can make gross inefficiencies easier or harder to find. Haskell just can't
be used in practice unless one tracks down and fixes space leaks. I don't want
to be debugging "time leaks" caused by unexpected call-by-name as well!

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

John Hughes