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.schonw...@gmail.com>: > > > On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani <takenobu...@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...@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 <cgibb...@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" <j...@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...@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@haskell.org >>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>>>> > >>>>> _______________________________________________ >>>>> Haskell-prime mailing list >>>>> Haskell-prime@haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>>>> >>>> >>> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> >
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
