young-il@cit-vlsi.Caltech.Edu (Young-il Choo) (07/11/87)
In article <1332@ssc-vax.UUCP> dickey@ssc-vax.UUCP (Frederick J Dickey) writes: >In article <1345@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes: >> >> I do not yet see the advantages to lazy evaluation except in a few cases >> which are academically interesting but of little practical use (all of which >> involve an exact representation of an infinite sequence, [...] >> [...] However, lazy evaluation is not supportable in >> imperative languages as it is an 'evaluate on demand' strategy for function >> parameter evaluation. All imperative languages evaluate the arguments to >> functions before the function is invoked. [...] > > [...] 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. This was, to me at least, a counterintuitive result, since >the "normal" way of passing parameters seems a lot simpler. I am inclined >to regard this clash between theory and practice as a "hint" from theory >that there is something wrong with the conventional view of parameter passing. Three points regarding the latest discussion on lazy evaluation. 1. It is true that most (all?) imperative languages do not have lazy evaluation of function parameters, but that does not mean they do not have lazy evaluation. Consider if exists(file) then read(file) else message "file does not exist!" fi which must be evaluated lazily, and all imperative languages do. Without lazy evaluation, the whole if-statement would result in error, should the file not exist. 2. From a theoretical point of view, lazy evaluation is the more "natural" evaluation strategy because it is the more general. For pure type-free lambda-calculus, the normal order (lazy) evaluation is guaranteed to produce a normal form if the lambda term has a normal form, while the applicative order (strict) evaluation may not terminate. 3. The reason for prefering the applicative order evaluation is that for most instances it can be faster. Young-il Choo --------------------------------- young-il@csvax.caltech.edu Caltech Computer Science Pasadena [seismo,rutgers,ames]!cit-vax!young-il