Editing Seq (section)

=== History ===

The need to specify an order of evaluation in otherwise-nonstrict programming languages has appeared before:

<blockquote>
We can use <code>VAL</code> to define a "sequential evaluation" operator which evaluates
its first argument and then returns its second:

<pre>
a ; b = (λx. b) val a
</pre>

and we can define other functions which control evaluation order [...]

:<small>[https://www.cs.ox.ac.uk/files/3309/PRG40.pdf The Design and Implementation of Programming Languages] (page 88 of 159)</small>.
</blockquote>

<blockquote>
 `seq' applied to two values, returns the second but checks that the first value is not completely undefined. Sometimes needed, e.g. to ensure correct synchronisation in interactive programs.
<pre>
> seq :: *->**->** ||defined internally
</pre>

:<small>[https://www.cs.kent.ac.uk/people/staff/dat/miranda/stdenv.html The Miranda Standard Environment © Research Software Limited 1989]</small>
</blockquote>

and in Haskell since at least 1996:

<blockquote>
The <code>seq</code> combinator implements sequential composition. When the expression <code>e1 ‘seq‘ e2</code> is evaluated, <code>e1</code>
is evaluated to weak head normal form first, and then the value of <code>e2</code> is returned. In the following parallel <code>nfib</code>
function, <code>seq</code> is used to force the evaluation of <code>n2</code> before the addition takes place. This is because Haskell does not
specify which operand is evaluated first, and if <code>n1</code> was evaluated before <code>n2</code>, there would be no parallelism.

<haskell>
nfib :: Int -> Int
nfib n | n <= 1    = 1
       | otherwise = n1 ‘par‘ (n2 ‘seq‘ n1 + n2 + 1)
                     where
                       n1 = nfib (n-1)
                       n2 = nfib (n-2)
</haskell>

:<small>[https://web.archive.org/web/20040228202402/http://www.dcs.gla.ac.uk/fp/workshops/fpw96/Trinder.pdf Accidents always Come in Threes: A Case Study of Data-intensive Programs in Parallel Haskell] (page 2 of 14).</small>
</blockquote> 

...the same year <code>seq</code> was introduced in Haskell 1.3 as a method of the (now-abandoned) <code>Eval</code> type class:

<haskell>
class Eval a where
   strict :: (a -> b) -> a -> b
   seq    :: a -> b -> b

   strict f x = x ‘seq‘ f x
</haskell>

However, despite that need by the time Haskell 98 was released <code>seq</code> had been reduced to a primitive strictness definition. But in 2009, all doubts about the need for a primitive sequencing definition were vanquished:

<blockquote>
<b>2.1 The need for</b> <code>pseq</code>

The <code>pseq</code> combinator is used for sequencing; informally, it
evaluates its first argument to weak-head normal form, and then evaluates
its second argument, returning the value of its second argument.
Consider this definition of <code>parMap</code>:

<haskell>
parMap f []     = []
parMap f (x:xs) = y ‘par‘ (ys ‘pseq‘ y:ys)
   where y  = f x
         ys = parMap f xs
</haskell>

The intention here is to spark the evaluation of <code>f x</code>, and then
evaluate <code>parMap f xs</code>, before returning the new list <code>y:ys</code>. The
programmer is hoping to express an <i>ordering</i> of the evaluation: <i>first</i>
spark <code>y</code>, <i>then</i> evaluate <code>ys</code>.

:<small>[https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/multicore-ghc.pdf Runtime Support for Multicore Haskell] (page 2 of 12).</small>
</blockquote>

Alas, this confirmation failed to influence Haskell 2010 - to this day, <code>seq</code> remains just a primitive strictness definition. So for enhanced confusion the only Haskell implementation still in widespread use now provides both <code>seq</code> and <code>pseq</code>.