firth@sei.cmu.edu (Robert Firth) (07/10/87)
First, to correct a misapprehension. It is not true that all imperative languages evaluate the arguments to a function before the call. The Algol-60 'call by name' is an obvious counterexample: f(expr) causes 'expr' to be passed as a thunk, ie a parameterless procedure, and this thunk is invoked whenever the body of f references the formal. Secondly, different languages mean different things by 'evaluation'. For example, consider the Algol-68 expression f(expr) If f is defined as PROC(INT)INT then expr is evaluated to yield an integer value, just as in Algol-60 call by value. But if f is defined as PROC(PROC INT)INT then expr is evaluated to yield an integer procedure, which is equivalent to call by name. In language terms, this is evaluation at the point of call, but it mimics delayed evaluation. However, neither of these is true lazy evaluation, because the expression may be evaluated more than once. In applicative languages, repeated evaluations of an expression always yield the same result, so we can replace delayed evaluation by true lazy evaluation, ie evaluate once only when first referenced. But the Algol-60 scheme does give you one benefit of lazy evaluation: if the formal is not referenced, the actual is not evaluated, and so the call f(expr) can still be valid even when the evaluation of expr will fail or fail to terminate. How easily this can be described depends on your descriptive apparatus. But if your compiler is going to implement routine hoisting (pragma INLINE) then you had better be able to replace the call with something that captures exactly the semantics of parameter evaluation, and if the language in question can't do that, you have to be careful, since you are transforming the attributed tree into something from which legal source code cannot be reconstructed.
willc@tekchips.TEK.COM (Will Clinger) (07/10/87)
In article <1332@ssc-vax.UUCP> dickey@ssc-vax.UUCP (Frederick J Dickey) writes: > ....My recollection is that >"lazy evaluation"-type parameter passing strategies are much easier to >describe formally than the way parameter passing is usually done in >imperative languages. It depends on the kind of formal semantics you're using. In the simplest kind of denotational semantics, known as a "direct" semantics, a by-name strategy is slightly simpler to describe. In a "standard" semantics, which is the kind needed to describe most real-world programming languages, by-value is simpler. In some operational semantics, such as the rewrite rules used by lambda calculus, by-name seems slightly simpler to me, but I've found by-value to be simpler when using rewriting rules as an operational semantics for nondeterministic languages. Finally, the beta-substitution rule that characterizes by-name and seems so desirable in a deterministic world causes trouble in a nondeterministic world. So I don't pay much attention to arguments based on the alleged semantic simplicity or complexity of by-name or by-value arguments. I think it's a software engineering issue, and that both have their place. Peace, Will Clinger Tektronix Computer Resea qke tve
rehbold@uklirb.UUCP (07/13/87)
I too think that the software engineering aspect is an important feature of lazy evaluation. Since lazy functions always produce only as much data as some other function really uses the generating function can be written completely independent from the using one. In imperative languages, all data generation and using has to be done in the *same* procedure; otherwise no coordination would be possible. Even if the stream of data to be generated is not infinite, no one would like the idea of first generating a lot of data and then using it, perhaps only needing some of the data because the solution was found quite early. It's this separation between generating and consuming functions that enables the programmer to write clean, modular and easy to understand programs without having to think about coordination problems, because these don't appear with lazy evaluation. Robert Rehbold University of Kaiserslautern, FRG UUCP: ..!mcvax!unido!uklirb!rehbold