John> There's an easier way to force structures hyperstrictly. To
John> force x to be evaluated to normal form before computing y,
John> write (x==x) `seq` y
I'm heavily confused here.
What happens, if
(a) an optimizer replaces (x==x) by True?
If the optimizer is not permitted to do that,
its power appears to be limited severely.
(b) a run-time system thinks pointer equality implies value equality?
Neither of these is permitted by Haskell's semantics. Firstly, == is just an
overloaded operator and the programmer is free to define it however he likes
(even stupidly). Secondly, even if the type of x is known -- say Int -- so
that the code for == is known, the optimizer may not replace code by a more or
less lazy `equivalent'. `Optimizing' x==x to True would change the meaning of
the program when x is undefined; comparing pointers to x instead of evaluating
x would equally be wrong.
As far as the power of the optimizer is concerned, my guess is programmers
very rarely write x==x (unless they MEAN to force x!), so the loss of
optimization doesn't matter. Of course, in principle, an optimizer *could*
replace x==x by x`seq`True (if x is known to be of base type), and the x`seq`
might well be removed by later transformations (if x can be shown to be
defined, something compilers do analyses to discover). Who knows, maybe this
happens in the innards of ghc...
John Hughes
