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

Re: Issue: PUSH-EVALUATION-ORDER (Version 3)

    Date: 9 Nov 87 16:19 PST
    From: Masinter.pa@Xerox.COM

    I'm a little uneasy about "Explicitly state that for the macros
    CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
    where CLtL specifies to the contrary."

I was trying to complete the set of references to macros affected by the
proposal, but I agree that this wording is poor.  I'm not sure what to
replace it with, though.

    I think that we also have to be careful about the following: suppose a
    user defines

    (defmacro wrong-order (x y) `(get ,y ,x))

    If the user writes (push a (wrong-order (frob) (baz)))

    are we willing to guarantee that "the subforms of the macro call
    (including but not limited to subforms of the generalized variable
    reference) are evaluated exactly as many times as they appear in the
    source program, and in exactly the same order as they appear in the
    source program. "?

Good point, and note that the same issue arises for
(setf (wrong-order (frob) (baz)) 1), so this point in no way shoots down
what we originally set out to do on the PUSH-EVALUATION-ORDER issue.

A more complicated version of wrong-order, for example, one with a loop
in it, would make it impossible to guarantee that statement.  So we have
to change the statement.  Ick.  I think what we mean is that evaluation of the direct subforms
of the macro call and of generalized-variable references in the macro
call is ordered, but evaluation of subforms of those subforms is determined by the
recursive evaluation process as normal.  I'd have to think about this more
to see if this is the best way to say it, it doesn't strike me as a model
of clarity.

    Similarly if the user writes an "incorrect" setf-method, e.g.,

    (defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z))

This is not an issue since CLtL p.103 says "This binding permits the
body forms to be written without regard for order-of-evaluation issues."
Of course a user could write an incorrect define-setf-method.

    I wish this weren't so sticky. . . .

Me too.  I think it's inherent in defining the order of evaluation of
things that aren't functions, so there's no easy answer.