Evaluation order control between two expressions

Sat Apr 30 14:20:46 UTC 2016

On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani <takenobu.hs at gmail.com> wrote:

> Hi Prime,
>
> This is additional information to organize my brain.
>
> This issue also occurs in single thread.
> Especially, when they have side effects.
>
>    seq exp1 exp2
>
> Because compiler can always re-order two expressions
> in accordance with seq's denotational semantics.
>
> Regards,
> Takenobu
>

That requires / presumes a none idempotent use of unsafe perform io in
those  sub expressions right?

>
> 2016-04-30 16:11 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:
>
>> 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
>>>>
>>>
>>
> _______________________________________________
> 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/62db770e/attachment-0001.html>