seq vs. pseq

Simon Marlow simonmarhaskell at
Wed Nov 8 08:23:34 EST 2006

Malcolm Wallace wrote:
> Simon Marlow <simonmarhaskell at> wrote:
>>>When I use `seq`, it is sometimes in a construction like
>>>    unsafePerformIO (emit "squawk!) `seq` x
>>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,
>>because  it gives implementations more flexibility.
> Hmmm.  I absolutely agree with the general point that Haskell should, as
> much as possible, not mandate any specific operational behaviour.  But
> what if I want to _observe_ or record the actual operational behaviour
> of some particular implementation?  For instance, to generate a heap
> profile, or a computational trace, or a coverage log, or something.  The
> results may well be different for every different implementation, and I
> am perfectly happy with that.  I may actually want to see the
> differences.  But do you really want to say "The Haskell language
> provides the programmer no mechanism to observe this"?  "Use some other
> language, or some compiler-specific hack"?  To me, it is unacceptable to
> be prevented from write an observational tool for a language in the
> language itself.

Yes, I'm saying you have to do something compiler-specific in order to observe 
the operational behaviour.  Now that may well be unsafePerformIO+seq on compiler 
X, but the point is that this isn't guaranteed to do what you want on all 
implementations, precisely because we want to admit different evaluation strategies.

What does it even *mean* to "evaluate x before y"?  For example, we might have 
an evaluation strategy that uses spare CPUs to search for unevaluated objects in 
the heap and speculatively evaluate them for a while; we might thereby evaluate 
y (or some of y's free variables) at any time, and even revert y from an 
evaluated to an unevaluated state.  By even saying that there's a concept of 
"evaluation order" you've already nailed too many doors shut, IMO.

> Especially since we already have a couple of features in the language
> that _do_ affect the operational behaviour.

what are you referring to specifically?  hGetContents is the only one I'm aware of.


More information about the Glasgow-haskell-users mailing list