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

[Dominic Steinitz]

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

[snick]

> > isum 0 s = s
> > isum n s = isum (n-1) (s+n)
> 
> This is tail recursive, and will be optimized to an iterative loop; 

[snick]

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

Dominic.

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.