#

## 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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.