pseq strictness properties

[Claus Reinke]

>> I don't think I'm just speaking for myself when I say that pseq is
>> confusing and the docs similarly.
>> 
>> Given the type
>> 
>> a -> b -> b
>> 
>> we would assume that it is lazy in it's first arg and strict in the
..
> I'm not quite sure what this distinction means, actually.

If I recall the issue correctly:

- 'seq' is strict in both parameters (in the second, by being like
    'flip const', and in the first, by its special nature).
- given that both parameters are thus needed, there is nothing
    to force the 'a' to be evalutated *before* the 'b'; many programs 
    using 'seq' tend to rely on this property (which the implementation 
    is free to ignore).
- 'pseq' is still strict in both parameters, but was meant to offer
    better evaluation-order guarantees than 'seq' does.

- a strict variant of 'case', somewhat like 'case a of !a -> b',
    might express the intent more closely but then one would
    want to abstract over it for composition, running back into 'seq'.

Hope this isn't too far off;-)
Claus

ps. it is unfortunate that the docs try to explain evaluation order
    in terms of how the compiler reacts to manipulating its knowledge 
    about strictness. Strictness of both 'seq' and 'pseq' is as one would
    expect, and how the intended evaluation order guarantee is achieved
    is strictly and subtly an implementation matter (not permitting any
    transformations would also work, for instance).