[Haskell-cafe] Re: Problems with strictness analysis?

[Achim Schneider]

wren ng thornton <wren at freegeek.org> wrote:

> 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.