Evaluation order control between two expressions

[Cale Gibbard]

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" <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>
> 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
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> 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/20160429/325cd492/attachment-0001.html>