RE: How to force evaluation entirely?
Simon PJ says: Did you try "seq"? x `seq` y should evalute x to WHNF before returning y. If x is a pair you may need to say seqPair x `seq` y where seqPair (a,b) = a `seq` b in order to force the components. Simon There's an easier way to force structures hyperstrictly. To force x to be evaluated to normal form before computing y, write (x==x) `seq` y This depends on all the types occurring in x being Eq types, and also on the implementation of == being hyperstrict when its result is true. This holds for all derived instances, and for most programmer defined ones too. After all, if x==x holds for any non-total x, then x==y must hold for some pair of different values x and y, which we normally try to avoid! I sometimes write if x==x then y else error "I am the pope!" but the seq form is nicer! John Hughes | -Original Message- | From: Michael Marte [mailto:[EMAIL PROTECTED]] | | | | I am trying to process a huge bunch of large XML files in order | to extract some data. For each XML file, a small summary (6 integers) | is created which is kept until writing a HTML page displaying the | results. | | The ghc-compiled program behaves as expected: It opens one | XML file after | the other but does not read a lot. After some 50 files, it | bails out due | to lack of heap storage. | | To overcome the problem, I tried to force the program to | compute summaries | immediately after reading the corresponding XML file. I tried | some eager | application ($!), some irrefutable pattern, and some | strictness flags, but | I did not succeed.
Re: How to force evaluation entirely?
"Ch. A. Herrmann" wrote: Hi, 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 an optimizer did that it would be severly broken in several ways. First, there is absolutelty no guarantee that the (==) operator defines anything that is a reflexive relation. E.g., I can (for a particular type) define it to always return False if I like. Second, even if (==) was defined to be reflexive it's highly likely that `x==x' would behave differently than `True'. The former probably diverges if x is bottom, whereas the latter doesn't. If the optimizer is not permitted to do that, its power appears to be limited severely. Who said Haskell was easy to optimize? -- Lennart
Re: How to force evaluation entirely?
John Hughes [EMAIL PROTECTED] writes: 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... Or the compiler could internally create its own HyperStrict class and replace x==x by x`hyperSeq`True, if all the Eq instances involved in the type of x are known to be reflexive (which is the case if they were all automatically derived). :-) Carl Witty
