Re: seq vs. pseq

Malcolm Wallace wrote:

Ross Paterson wrote:

...

When I've used seq, it's to ensure that a function is strict in that argument, and therefore has been evaluated before the function is called. (If the language had unlifted types, I might have used those instead). Beyond that, I don't care exactly when it was evaluated; it might be long before, thanks to propagation of strictness information.

When I use `seq`, it is sometimes in a construction like

unsafePerformIO (emit "squawk!) `seq` x

where I am trying to force the impure side-effect to happen, exactly and immediately before x is evaluated. Whilst this is not good style in a general sense, I argue that it is perfectly safe inside certain kinds of library (e.g. for calculating coverage information, or for emitting tracing information). But if the language itself cannot guarantee this exact placement of side-effects, then it becomes impossible to write computation-reflective tools like Hat and hpc for Haskell, in Haskell. That would surely be a sad state of affairs.

My take on this kind of thing is that if you want a specific operational behaviour, then you're doing something implementation-specific. We shouldn't mandate any kind of operational behaviour across Haskell implementations. Yes, I'm saying you can't do this portably, and it is good that you can't, becauuse it gives implementations more flexibility. Cheers, Simon