Malcolm Wallace wrote:
Indeed, `seq` is widely viewed as a wart on the language _because_ it
specifies the evaluation order, which is something otherwise avoided in
the Report.
I don't agree with that statement - the main problem with (polymorphic) seq is
that its existence implies that the function type is lifted, which has
wide-ranging ramifications.
So the doubly bizarre thing is that, actually, `seq` does not control
the evaluation order (which is the only valid reason for wanting to use
it in the first place), but nevertheless it undesirably changes the
semantics of programs such that equational reasoning no longer holds.
I think if we are going to allow ourselves the luxury of semantic
breakage, it should at least be worth the cost - we should get some
real and definite operational control in return.
That is why I think this:
the evaluation-order property of seq should be a strong hint, not a
requirement - otherwise we fall into the trap of mandating evaluation
order.
is not strong enough. `seq` should guarantee sequential evaluation. If
you want a strong (but not mandatory) hint to the compiler about
strictness, than that should be a different construct at the user level.
Not "strictness" - seq already provides that, we're talking about an operational
property, that the language definition otherwise does not specify (I just want
to be clear about terminology).
GHC currently has seq and pseq; pseq guarantees sequential evaluation, seq does
not. You want seq to have the pseq behaviour, and to specify this in the report
(somehow - lacking any framework to describe operational properties this could
only be an informal statement). This would have some undesirable consequences.
In an expression like 'a `seq` b `seq` c', I bet in most cases the programmer
would be happy for a and b to be evaluated in parallel, but you would require
them to be evaluated in strict sequence. What's more, given this expression,
the strictness analyser would only be able to infer that 'a' was used strictly,
because if it also inferred b and c as strict then the simplifier might reorder
the evaluations (normally reordering the evaluation of arguments to a strict
function is perfectly ok). So lots of uses of seq to add strictness for
performance would simply not work.
Forcing seq to evaluate its arguments in strict sequence would be a really bad
idea. For those (few) times when you really do want sequential ordering, for
controlling parallelism, then we need pseq (call it something else if you want,
I'm not fussy about names).
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
