Talk:Lazy evaluation
From Academic Kids
Surely it is expressions which are evaluated, not variables? -- The Anome
Yes, I think that's the usual way to say it. If you have referential transparency, like Haskell, then it doesn't make much difference. It's been a while since I did much Scheme, and I don't think it had delayed variables then, but around R4RS there was a promise function, that delayed evaluation of an expression, and force to deliver on a promise.
So, IMHO, we should talk about expressions first, with delayed variables as one possible way of expressing lazy evaluation.
We should also say something about graph versus tree reduction.
I'm not sure if the analogy to XWindow's windowmanagers is valid. AFAIK, the windowmanager in X is only responsible for the contents and behaviour of window borders, and manipulation of those. Exposing and redrawing window content is something part of the X protocol, and implemented by the 'widget set', a software library to help abstract drawing and manipulation of objects within a window.
Mark-Jan
The C/++ example with the compound predicate was wrong. I check Stroustrup (it was closer to hand than K&R), and C++ guarantees the same behaviour with these operators as Java does. If your compiler doesn't, it's broken. --Robert Merkel 05:03, 20 Apr 2004 (UTC)
- Actually I am not sure what the example is trying to show. Isn't it just an example of short-circuited evaluation? Besides, I don't see what a short-circuit has to do with lazy evaluation at all. -- Taku 05:11, Apr 20, 2004 (UTC)
- I agree with Taku -- if C was a language that documented that it might short-circuit an expression as an optimisation, the example could be valid. If I have time I'll look for a better example. I guess the right way to say it is that short-circuiting is lazy evaluation at the meta level: "In theory I want to evaluate myfunc(b), but in fact it is never needed". -- Mark Hurd 16:09, 19 Jun 2004 (UTC)
