[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sequential order of evaluation




Indeterminate order of evaluation of expressions in a procedure call.

Bill Rozas:
    Any sequential order is the intention.  Interleaving should not be
    allowed because there are no locking primitives to serialize side
    effects.

Chris Hanson:
    Certainly the implementation is free to use any SEQUENTIAL order.
    It has never been clear to me whether the specification permits
    simultaneous evaluation of two different arguments.

Mike Shaff:
    This being the case (and presuming this is the generally agreed thinking)
    shouldn't this choice be made more explicit.  I think the absence of said
    locking primitives (at the current time) is an issue whose ramifications
    should be noted.

The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
Thus it is ok to evaluate

    ((f (car x)) (g (car x)))

as though it were

    (let* ((t1 (f (car x)))
           (t2 (g (car x))))
      (t1 t2))
or
    (let* ((t2 (g (car x)))
           (t1 (f (car x))))
      (t1 t2))

but it is not ok to evaluate it as though it were

    (let* ((t0 (car x))
           (t1 (f t0))
           (t2 (g t0)))
      (t1 t2))
or
    (let* ((t0 (car x))
           (t2 (g t0))
           (t1 (f t0)))
      (t1 t2)).

The problem with saying that the evaluation must be sequential is that the
word "sequential" isn't very well-defined.  Some people think only the first
of the four is sequential, and some think all four are sequential.

How do the authors feel about adding the following note to section 4.1.3?

    Note:  Although the precise order of evaluation is unspecified, the
    expressions must be evaluated without interleaving.  Interleaving is
    not allowed because Scheme provides no facilities for serializing
    concurrent side effects.