[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue FUNCTION-CALL-EVALUATION-ORDER Writeup

Status:       passed v2 on 15-0 vote, Jun-90

Issue: FUNCTION-CALL-EVALUATION-ORDER

References: CLtL p 194 ("...that order is always left to right")

ANSI CL spec (Aug 29, 1989 draft) p.4-10 3rd paragraph

Category: CLARIFICATION

Edit history: Version 1 by Clinger (22 March 1988)

Version 2 by Moon (1 Feb 90), add MORE-UNSPECIFIED

Problem Description:

CLtL does not say whether the function expression of a call is evaluated

before or after the argument expressions.

This is Symbolics issue #4.

Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):

Common Lisp does not specify whether the function expression of a call is

evaluated before or after the argument expressions. Programs that rely

on a particular order of evaluation are in error.

The above proposal was accepted in October 1988. The following proposal

is new in version 2.

Proposal (FUNCTION-CALL-EVALUATION-ORDER:MORE-UNSPECIFIED):

Common Lisp does not specify whether the function expression of a call is

evaluated before the argument expressions, after the argument

expressions, or between any two argument expressions if there is more

than one argument. Programs that rely on a particular order of

evaluation are in error.

Example:

(defun foo (x) (+ x 3))

(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))

(foo (progn (bar) 20))

; may return 23 or 24

(defun foo2 (x y) (+ x y))

(defun bar2 () (setf (symbol-function 'foo2) #'(lambda (x y) (* x y))))

(defun bar3 () (setf (symbol-function 'foo2) #'(lambda (x y) (- x y))))

(foo2 (progn (bar2) 6) (progn (bar3) 7))

; under UNSPECIFIED, may return 13 or -1

; under MORE-UNSPECIFIED, may return 13, -1, or 42

Rationale:

UNSPECIFIED makes the status quo explicit.

MORE-UNSPECIFIED allows complete freedom to the implementation; as long

as we are not going to require all implementations to be consistent, it

seems useless to impose half a restriction on the implementation. Some

RISC machines with delayed branches would prefer to evaluate the function

between evaluating the penultimate argument and the last argument in

some situations.

Current Practice:

TI and Symbolics used to evaluate the function expression last.

Symbolics currently evaluates the function expression either first or

last depending on the hardware and whether the code is compiled or

interpreted. I'm not sure if TI has changed in the past two years.

Lucid and Coral sometimes evaluate the function expression first and at

other times evaluate the function expression last.

Cost to implementors:

None.

Cost to users:

None.

Benefits:

Codifies an ambiguity.

Aesthetics:

Since Common Lisp evaluates argument expressions from left to right, it

would be more consistent for the function expression to be evaluated

before the argument expressions. On the other hand, the evaluation rules

for function expressions are already quite different from the rules for

argument expressions, and nobody in their right mind would write code

that depends on the order of evaluation, so aesthetics should not count

for much in this case. Requiring left to right evaluation would force

some implementations to consume an extra register for many function

calls. The efficiency argument seems more important than the aesthetic

argument.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.