View source for Sequential ordering of evaluation

[[Category:Proposals]]


The <code>seq</code> primitive, despite its name, is not required to evaluate its parameters in some predefined order, according to the Haskell 2010 Report. For
parallel programming, sometimes a variant of <code>seq</code> is needed with
such an ordering:

<blockquote><tt>While we focus mainly on the implementation, our work has had some impact on the programming model: we identify the need for pseq as well as seq (Section 2.1), and we isolated a signficant difficulty in the "strategies" approach to writing parallel programs (Section 7).</tt></blockquote>

* [https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/multicore-ghc.pdf ''Runtime Support for Multicore Haskell'']; Simon Marlow, Simon Peyton Jones and Satnam Singh.

Instead of two or more similar primitives with similar purposes, extend the existing <code>seq</code> primitive with the traditional ordering of evaluation for its parameters - first, then second; with the role of simple strictness-control being performed by a new primitive with a more appropriate name e.g.
<code>amid</code>, in [[Strictness without ordering, or confusion]].

[[User:Atravers|Atravers]] 02:00, 7 January 2019 (UTC)