pseq strictness properties
claus.reinke at talk21.com
Thu Nov 20 19:05:10 EST 2008
>> 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;-)
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).
More information about the Glasgow-haskell-users