wren ng thornton
If Haskell had strictness annotations as part of the type system, then there might be room for progress. We could imagine constructing separate polymorphic bodies for isum, one for each strictness variant of (+). Then, when isum is instantiated at types which define strict (+) we could use an optimized version of isum that forces evaluation at each step. Now the trick becomes how to control the explosion of generated code for all the combinatorially many strictness variants of types. For whole-program optimizing compilers, it should be relatively easy to keep the code bloat down, but for separate compilation it's not so straightforward. Chances are that any solution along this route would still require strictness annotations in order to do the right thing, only now we've lifted the annotations into the type language instead of leaving them in the term language.
Code explosion is actually what we want, as things like (+) are best if unboxed and inlined, to one of the thousands of machine instructions the target architecture offers for that operation (think x86, amd64, x87, mmx, sse, sse2...). As a side note, you made me think about y-combinators, stream fusion and lists of computations that can be rewritten to use the minimum number of y's possible/computable. It appears to have a lot in common with strictness/eagerness if you eg. think of [n..] as a fixpoint of the form y (\num_calls -> num_calls + n). FP semanticists will now cry "Heresy! Repeat after me: Pure is pure and impure is impure, always and ever", so I rather shut up and think before I make even less sense. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.