seq vs. pseq

[Simon Marlow]

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