Evaluation order control between two expressions

[Lennart Augustsson]

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 <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
> <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 at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org <javascript:;>
> 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/20160430/b60da517/attachment.html>