[Haskell-cafe] Re: Problems with strictness analysis?
dominic.steinitz at blueyonder.co.uk
Tue Nov 4 06:26:36 EST 2008
wren ng thornton <wren <at> freegeek.org> writes:
> > isum 0 s = s
> > isum n s = isum (n-1) (s+n)
> This is tail recursive, and will be optimized to an iterative loop;
> In terms of having a compiler 'smart enough', it's not clear that
> functions of this sort ought to be inferred strict simply because the
> accumulator is ultimately returned to the caller. Consider for example:
I thought this was strict as Luke Palmer has already pointed out. My
understanding is that a compiler may be able to infer it is strict and then
perform eager evaluation.
> > f 0 xs = xs
> > f n xs = f (n-1) (replicate n n ++ xs)
> Since (++) can indeed return partial answers, it's fine for the
> accumulator to be lazy. Indeed, making it strict harms performance
> significantly. Another example is when the accumulator is a function, as
Can this function be strict if (++)isn't? And if it isn't strict, why would it
make sense to evaluate it eagerly?
PS This subject seems to come up often enough to be worth a wiki entry (maybe
there already is one). I think we should also be careful with terminology (as
Luke Palmer and David Menendez have pointed out. Maybe that could be included
in the wiki entry.
More information about the Haskell-Cafe