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).