What does seq actually do in Haskell?
From Real World Haskell I read
It operates as follows: when a
seqexpression is evaluated, it forces its first argument to be evaluated, then returns its second argument. It doesn't actually do anything with the first argument:seqexists solely as a way to force that value to be evaluated.
where I've emphasised the then because to me it implies an order in which the two things happen.
From Hackage I read
The value of
seq a bis bottom ifais bottom, and otherwise equal tob. In other words, it evaluates the first argumentato weak head normal form (WHNF). seq is usually introduced to improve performance by avoiding unneeded laziness.A note on evaluation order: the expression
seq a bdoes not guarantee thatawill be evaluated beforeb. The only guarantee given byseqis that the bothaandbwill be evaluated beforeseqreturns a value. In particular, this means thatbmay be evaluated beforea. […]
Furthermore, if I click on the # Source link from there, the page doesn't exist, so I can't see the code of seq.
That seems in line with a comment under this answer:
[…]
seqcannot be defined in normal Haskell
On the other hand (or on the same hand, really), another comment reads:
The 'real'
seqis defined in GHC.Prim asseq :: a -> b -> b; seq = let x = x in x. This is only a dummy definition. Basicallyseqis specially syntax handled particularly by the compiler.
Can anybody shed some light on this topic? Especially in terms of:
- What source is right?
- Is
seq's implementation really not writable in Haskell?- If so, what does it even mean? That it is a primitive? What does this tell me about what
seqactually does?
- If so, what does it even mean? That it is a primitive? What does this tell me about what
- In
seq a bisaguaranteed to be evaluated beforebat least in the case thatbmakes use ofa, e.g.seq a (a + x)?