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

Dominic Steinitz dominic.steinitz at blueyonder.co.uk
Tue Nov 4 06:26:36 EST 2008


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.



More information about the Haskell-Cafe mailing list