
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