
Robin Green wrote:
On Fri, 3 Feb 2006 19:33:12 -0000 "Brian Hulley"
wrote: I've been thinking along these lines too, because it has always seemed to me that laziness is just a real nuisance because it hides a lot of inefficiency under the carpet as well as making the time/space behaviour of programs difficult to understand...
One question is how to get some kind of "do" notation that would work well in a strict setting. The existing "do" notation makes use of lazyness in so far as the second arg of >> is only evaluated when needed. Perhaps a new keyword such as "go" could be used to use >>= instead ie:
go {e1;e2;e3} === e1 >>= (\_-> (e2 >>= (\_->e3)))
That's not necessary. >> has something in common with if', where
if' True x _ = x if' False _ y = y
- in both cases, it makes sense to evaluate the arguments lazily.
So simply make strictness the default and have laziness annotations (for arguments), instead of making laziness the default and having strictness annotations.
Where would you put these laziness annotations? If you put them in the function declaration eg as in: if' :: ~a -> ~b -> Bool presumably you'd want the compiler to pass the args as thunks instead of evaluated values. However this means that all args to every function would have to be passed as thunks, even though for strict functions these thunks would immediately be evaluated. The problem is that there is no way for the compiler to optimize out the thunk creation / evaluation step because it occurs across the "black box" of a function call, thus we wouldn't get the same efficiency as in a language such as ML where no thunks are created in the first place. Ie there is a fundamental asymmetry between lazy annotations and strict annotations - it is trivial to go from lazy to strict before the function body is evaluated but impossible to unevaluate from strict back to lazy... Regards, Brian.