Evaluation order control between two expressions

Sun May 1 00:47:38 UTC 2016

Hi Carter,

You are right. I had mixed case.
In single thread case, I implicitly assumed IO context rather than pure
parallel context.

Thank you for explanation.

Regards,
Takenobu

2016-04-30 23:20 GMT+09:00 Carter Schonwald <carter.schonwald at gmail.com>:

>
>
> 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/20160501/20aa0ac8/attachment-0001.html>