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

left to right order of evaluation



    Date: 21 November 1984 14:11-EST
    From: George J. Carrette <GJC>

    ; Is (F) => "left to right is strict"
    ;     or => "left to right is violated"

    The question is, does common-lisp define the result of (F) in
    this case?

I remember once looking in the CL manual for a definition of argument
evaluation order, and not finding any.  (My apologies if I am ignorant
of some previous discussion of this.)

Options:

(a) It was left undefined and was meant to be left undefined (perhaps
because there was no agreement as to whether or not to define it!).

(b) It was defined to be left-to-right, or it was meant to be
defined and if the manual doesn't say so it was an oversight.

In case (a), I think that, because (probably) all implementations are
left-to-right, if any CL implementation actually came along which was
not left-to-right, 70% of real CL programs would fail to work, bombing
out in very obscure ways.  I don't think that users will be able to
restrain themselves from depending on evaluation order unless either
their compiler generates argument-interaction warnings like RABBIT does,
or they are forced to deal with non-left-to-right implementations, or
both.

In case (b), there's the problem GJC brings up.  The consistent thing
would be to do the function position before anything else, but
implementors will probably complain that that will slow everything down
(which is true).  Inconsistent things to do would be to compute the
function last, or to leave the time at which the function is computed
undefined (as in Maclisp - first in interpreted code, last in compiled).
Either of these would be pretty bizarre, in my opinion, given that
arguments are evaluated left-to-right.  But I suspect one or the other
such bizarre behavior is what many CL implementations out there exhibit.

(Certainly if CL is left-to-right then E1 would have to be evaluated
before E2 in (FUNCALL E1 E2); if CL has the first "bizarre" behavior as
described in previous paragraph, then a compiler must not rewrite
(FUNCALL #'G (I)) as (G (I)) unless it can prove that calling I will
not assign #'G.)

So we have a problem either way.