Hello Takenobu,
Great question, this is actually a pretty interesting issue! It isn't
out of scope at all.
The first thing to think about is the following thought experiment:
Without the presence of side-effects, how can you tell the difference
between a `seq` that conforms to the Haskell report and one that
evaluates it's first argument before its second?
If your answer involves `unsafePerformIO` then you're cheating ;)
Even if your first argument to `seq` is an IO action it won't get
executed because `seq` only evaluates to WHNF. It might be possible to
construct a program that allows you to observe the difference, but in
the general case I don't see how you could. I'd be very interested to
be shown otherwise though!
Now in a parallel program things change. When we use `pseq` it's
because we don't want two threads to collide when trying to evaluate
the same expression. Let's look at an example:
x `par` y `seq` x + y
As you noted, the semantics of `seq` doesn't actually guarantee that
`y` will be evaluated before `x + y`. But this only matters because
we've used `par` and introduced threads (via an effect!) and therefore
the possibility of collision. We can avoid this by using `pseq`
instead.
So, both `seq` and `pseq` both allow the programmer to express
*operational* concerns, `seq` is used mostly to eliminate/manage space
leaks, and `pseq` is used to specify order of evaluation. Those
concerns sometimes overlap, but they are different!
It could be argued (and I would agree) that `seq` is a bad name; a
better name might have been something like `synch` [1]. That being
said, unless we add parallelism to the standard (and even then) I am
not sure it would be wise to change the operational behavior of `seq`.
It's current behavior is well established, and if you're writing
sequential Haskell code where order of evaluation matters, it's
probably better to reach for a different tool (IMO). However, if
parallelism is introduced then I'd fight for `pseq` to be part of that
(as you suggest).
I hope that sheds some light on the issue.
Cheers,
Jose
[1]: John Hughes introduced a `synch` combinator in his thesis, but it
had very different semantics, so maybe that's a reason it was avoided?
Someone with more knowledge of the history can probably shed more
light on this.
On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani
Dear Community,
Apologies if I'm missing context.
Does Haskell 2020 specify evaluation order control by `pseq`?
We use `pseq` to guarantee the evaluation order between two expressions. But Haskell 2010 did not specify how to control the evaluation order between two expressions. (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't guarantee the order. [2])
I think it's better to explicitly specify `pseq` as standard way.
Already discussed? or out of scope?
[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006... [2]: https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evalu...
Regards, Takenobu
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime