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
