Order of evaluation can be very important for memory use. So I can imagine cases where seq would run out of memory, but pseq would not.
I would argue that pseq is almost always what you want, but seq has a nicer denotational semantics. -- Lennart On Friday, April 29, 2016, 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 > <javascript:;>> 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 <javascript:;> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org <javascript:;> > 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