you don't actually need lazyness.
(except if you tried to define >> directly instead of using >>= as the
primitive because then the second parameter would be an action directly
instead of a continuation)
yes, you'd want >> to be non-strict in its second parameter.
Thanks! This is *absolutely* the central problem in my understanding since I
never know whether I am allowed to assume that evaluation does not happen
under a lambda.
well, assumptions like that are on shaky ground in the presence of optimizing
compilers, but you can look at it this way: most functional languages, strict
and non-strict, assume evaluation of functions to weak head normal form,
stopping at the outermost lambda. formally, they probably ought to evaluate
at least a little further, to head normal form (lots of lambdas, then a variable
or an application with a variable in function position), but they don't --
(\x->undefined) and (\x->(\y->undefined)) are distinguishable in Haskell.
so, while an optimizing compiler will try to share expensive computations
in the body instead of reevaluating them every time a lambda is applied,
it is up to the compiler optimization writer to ensure that such evaluation
does not produce different effects than not evaluating under lambdas
(apart from improved resource utilization).
For example, if I wrote a C function:
int foo(int x, int y){
int z = 24 + 67 + 108 + x;
int w = 200 + y;
return z + w;
}
I would be very disappointed if the compiler didn't evaluate 24 + 67 + 108 +
200 at compilation time, whereas with:
foo x y = let
z = 24 + 67 + 108 + x
w = 200 + y
in z + w
a = foo 5
if I understand you correctly I should assume that the expression
(24 + 67 + 108 + 5) + (200 + y)
is left alone until the y argument is supplied to a, rather then a = foo 5
causing a to be bound to \y -> 404 + y
as it stands, the compiler can't know the type of y, so it can't know
whether (+) is even associative. if that is known, such optimization
may or may not happen, depending on the implementation. but if
such optimizations do take place, the resulting code must not
terminate less often or raise more errors than the original version.
cheers,
claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
