This passage in section 2.8 must have raised some eyebrows:
I have to say that I think the GHC approach is a bit of a hack. Why? Because it relies for its correctness on the fact that the compiler never duplicates a redex.
It can be restated as: The world-token-state-monad approach to compiling IO depends on lazy operational semantics to never duplicate redexes.
One consequence is that WTSM makes it more difficult to optimize for space rather than speed. A program optimized for space might resort to repeating work. That is, it might duplicate redexes, rather than store the voluminous results of that work for later sharing.
(If you talk to Oleg Kiselyov he's got HPC war stories about how this form of DRY-ness isn't the right default. That accounts for his present anti-laziness bent.)
Comments
This passage in section 2.8 must have raised some eyebrows:
An astute observation, thanks.
It can be restated as: The world-token-state-monad approach to compiling IO depends on lazy operational semantics to never duplicate redexes.
One consequence is that WTSM makes it more difficult to optimize for space rather than speed. A program optimized for space might resort to repeating work. That is, it might duplicate redexes, rather than store the voluminous results of that work for later sharing.
(If you talk to Oleg Kiselyov he's got HPC war stories about how this form of DRY-ness isn't the right default. That accounts for his present anti-laziness bent.)
AIUI Oleg's complaint is more about the compiler removing redexes or moving them about, rather than not duplicating them.
Redexes are elided for 2 reasons:
1. Redundant calculation: the result of the redex isn't used. Get rid of it.
2. The same redex occurs elsewhere. Reuse the result of that instead. Stay DRY.
Oleg has no problems with 1. Oleg has a beef with 2 because in HPC, the time-space tradeoff runs counter to ordinary intuition.