Claus Reinke wrote:
[snip]
(the picture is slightly less simple, as 1/2 are repeated, hence
construction and interpretation are interleaved, and later
construction may depend on the results of earlier interpretation, but I
assume you know that;)
This is one of the issues that I was confused about, but I think it's
getting clearer day by day :-)
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)
you don't even need >>= to be
non-strict in its second parameter, because that second parameter will be
a
continuation function, and even strict functional languages tend not
to evaluate under lambdas (so wrapping expressions in extra lambdas
or eta-extending functions to make their outer lambda explicit is a
standard technique to delay
evaluation in those languages).
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.
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
the standard papers do not make this very clear, but neither lazyness
nor static typing are needed to add a monadic i/o system to a purely
functional language (it took me a while to figure that out when I had
to decide how to add an i/o system to a purely functional language without
either
feature..).
Regards, Brian.
----------------------------------
"Have you the lion's part written? Pray you, if it be, give it me; for I am
slow of study"
-- Midsummer Night's Dream
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
