[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fsymeval before arg-eval?
- To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM@navajo.stanford.edu
- Subject: fsymeval before arg-eval?
- From: email@example.com (Jon L White)
- Date: Fri, 23 Jan 87 13:49:53 PST
- Cc: navajo!cfry%OZ.AI.MIT.EDU@navajo.stanford.edu, navajo!Common-Lisp%SU-AI.ARPA@navajo.stanford.edu
- In-reply-to: Daniel L. Weinreb's message of Fri, 23 Jan 87 10:47 EST
For compiled code, the macro/functional decision has been made at compile
time, and the question of order-of-evaluation is a legitimate question.
In fact, most implementations I'm aware of do the "fsymeval" *after* the
agruments computations in compiled code, but do it *before* them in the
In an implementation where the "macro-p" question is decidable without
looking in the function cell (like, MacLisp and Interlisp), then the
interpreter wouldn't need to do the fsymeval before doing the argument
The other issue is decidibility of "special-form-p"; in a language where
the "special forms" are immutable (expect for macro-expanders for semantics
clarity), there is no need to look into the funtion cell to determine
whether or not the form is a "special form". Lisp/370 was implemented
this way also (or was intended to have this semantics!); it is generally
true for Common Lisp too.
But the real issue is that evaluating the functional position last is
very counterintuitive. It certainly wouldn't survive the Lisp1/Lisp2
challenge (which is a proposal to unify the function and value cells).
As far as I know, only VAX/NIL did the fsymeval in compiled code before
the argument computations. Do you know of any others.
-- JonL --
P.S. Historical perspective: Another variant of this problem is discussed
in a footnote to the paper "Lisp: Data Is Program -- A Tutorial in
Lisp" found in the Proceedings of the 1977 MACSYMA Users' Conference
(NASA CP 2012). See page 197. This footnote is particularly concerned
with multiple "evaluations" of the function context -- such as has
recently been proposed for Common Lisp as a way to accommodate the
Lisp1/Lisp2 controversy -- and in particular the side-effects which
may occur in the "evaluations".