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 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
