Andrew Pochinsky wrote: > On Sep 11, 2009, at 6:46 PM, John Cowan wrote: >> Andrew Pochinsky scripsit: >>> Note: Although the order of evaluation is otherwise unspecified, >>> the >>> effect of any concurrent evaluation of the operator and operand >>> expressions is constrained to be consistent with some sequential >>> order >>> of evaluation. The order of evaluation may be chosen differently for >>> each procedure call. >> That means that evaluation of the expressions cannot be interleaved. > > The last sentence is relevant to the present discussion. What > application forms are "the same"? One can take a point of view that > each lexically distinct application expression is "the same" and has a > fixed order of evaluation of the procedure and arguments. Or one can > consider a procedure call to be a dynamical thingie that happens at > most once in the life time of the program. Modulo history of Lisp and > Scheme, RnRS does not favor one approach over the other.
"The order of evaluation may be chosen differently for each procedure call." A procedure call is a dynamic notion. An application expression, on the other hand, is a syntactic notion. There are no procedure calls in Scheme text, just as there are no procedures; there are application expressions, which result in procedure calls when evaluated, and there are lambda expressions which result in procedures when evaluated. So, the same syntactic occurrence of an application expression can, in general, cause any number of procedure calls to be made during the running of a program. To me, the intent is clear here. The mixing of static and dynamic language may be confusing, but I think we can be confident that for a given application, it may be evaluated in different orders while running the program. (So John Cowan's interpretation is correct, although he confuses the situation slightly by saying "It's permissible to use a different order of argument evaluation on every evaluation of the same procedure call." He really should have written "the same application expression.") David _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
