Evaluation order control between two expressions

Takenobu Tani takenobu.hs at gmail.com
Sat Apr 30 07:11:09 UTC 2016


Hi Jose and Cale,

Thank you for clear and detailed explanation.

short summary:

 * `seq`  used to eliminate/manage space leaks
 * `pseq` used to specify order of evaluation

 * `seq` is a bad name, but well established.
 * If we introduce parallelism to standard, we need `pseq` or some method.


It's depending on whether or not corresponding to the parallelism.
I learned a lot. Thank you very much.

Regards,
Takenobu

2016-04-30 8:17 GMT+09:00 Cale Gibbard <cgibbard at gmail.com>:

> Well, the value of par x y is identical to that of y, so any expression
> which you could use to semantically distinguish pseq from seq using par
> could be rewritten into one which did so without involving par.
>
> If the way in which we're telling programs apart involves performance
> characteristics then it may already be possible to distinguish seq from
> pseq. It somewhat comes down to whether the implementation of the language
> is clever enough to notice when compiling seq x y any cases where it might
> be better to finish evaluating y first and simply evaluate x before making
> the result of that first evaluation available. GHC does do this
> rearranging, so probably someone can come up with a good example there.
> On Apr 29, 2016 5:38 PM, "José Manuel Calderón Trilla" <jmct at jmct.cc>
> wrote:
>
>> 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 <takenobu.hs at gmail.com>
>> wrote:
>> > 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
>> > [2]:
>> >
>> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>> >
>> > Regards,
>> > Takenobu
>> >
>> >
>> > _______________________________________________
>> > Haskell-prime mailing list
>> > Haskell-prime at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>> >
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160430/a2d0a219/attachment.html>


More information about the Haskell-prime mailing list