Evaluation order control between two expressions

Sun May 1 02:42:42 UTC 2016

On Sat, Apr 30, 2016 at 8:47 PM Takenobu Tani <takenobu.hs at gmail.com> wrote:

> 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 your wonderful questions!

> 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/27f3d2ed/attachment.html>