The dreaded M-R

[Josef Svenningsson]

There has been many good arguments for and against the M-R in this thread.
But the most important argument against M-R hasn't been put forward yet.
Well, I think it is the most important argument anyway.

Haskell is, and has always been, a non-strict language. *Not* a lazy
language. Although many people on this list know this it is so easy to
forget that it is worth repeating. Haskell is *not* a lazy language.

There are many evaluation strategies one can use to implement Haskell. The
problem with the M-R is that it is a concern only in *some* of these
evaluation strategies, most notably lazy evaluation. That makes the M-R such
a strange thing to have in the specification of Haskell. If you read the
motivation section which defines the M-R ( 4.4.5 in Haskell98 report) the
report suddenly starts to talk about how many times a certain a certain
expression is evaluated. But nowhere in the report is it defined how
expressions should be evaluated. This makes the M-R truly butt-ugly!

Some might say: Well then, let's make Haskell lazy. All implementations are
lazy anyway!
No, not all implementations are lazy. And even if that were the case I think
it would be a big mistake to explicitly define Haskell's evaluation order.
There is a why Haskell was not specified as lazy in the first place.

But that doesn't mean that having a standardized lazy semantics for Haskell
would be a bad thing. It would be a very nice thing to have an addendum to
Haskell' which defined a standard lazy semantics. If it turns out that
people want the M-R after all it should be placed in such an addendum, which
actually talks about the evaluation order. However, I do realize that such
an addendum would be quite a bit of work to put together. Perhaps after
Haskell' is fixed we can start thinking about whether we have the need and
the stamina to put together such a thing.

Cheers,

/Josef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-prime/attachments/20060131/017983f0/attachment-0001.htm