seq vs. pseq

[Malcolm Wallace]

Simon Marlow <simonmarhaskell at gmail.com> wrote:

> The report is in general very careful to say absolutely *nothing*
> about  evaluation order, leaving the implementation free to choose,

Yes, this is a highly desirable goal.

> However, having said all that, arguably an exception should be made in
> this  case.  The main use of seq (and strictness annotations) is to
> control  operational behaviour, rather than to change the semantics of
> the program

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.

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.
At the moment, these alternatives are named `pseq` and `seq`.  One
suggestion is just to reverse their sense.  Another is to use bang
patterns for hints.  Another might be to introduce strictness hints in
type signatures.

Regards,
    Malcolm