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