Robin Green wrote:
On Fri, 3 Feb 2006 19:33:12 -0000
"Brian Hulley" <[EMAIL PROTECTED]> 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.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
