deeqSeq proposal

[Lennart Augustsson]

Simon Peyton-Jones wrote:
> | Any function that is not defineable in (pure) Haskell should be viewed
> | with utmost suspicion.  The seq function is one of these.  At least
> | seq has simple denotational semantics, which can't be said for
> deepSeq.
> | 
> | I say, put deepSeq in a type class (which is what I've done when I
> need
> | it).
> 
> The whole *point* is that deepSeq is (dynamically) idempotent: deepSeq
> (deepSeq x) = deepSeq x.  Its denotational behaviour is perfectly
> definable in Haskell, but its operational behaviour is not.  That is
> both attractive (because it means you feel less anxious about wasting
> work with deepSeq) and repellent (because it constrains the
> implementation, as John points out).
> 
> Whether it should be in a class is a rather separate discussion.  In a
> way we already sold out when we allowed seq to escape from the
> type-class world.  Perhaps deepSeq is worse (because it traverses data
> structures) but not obviously. 

Well, my worry was partly about the suggested version of deepSeq that
would not diverge on circular structures (since circular structures
are just one way to implement "infinite" data structures).

I think deepSeq is only worse than seq if we insist that it should
have some semantics that constrains implementations (like that the
second time you apply deepSeq it should be "fast").

I think it was a mistake to let seq out of the type class bag, but
that's already done.

	-- Lennart