[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
- To: masinter.PA@XEROX.ARPA, common-lisp@SU-AI.ARPA
- Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Sat, 18 May 85 14:11 EDT
- In-reply-to: The message of 18 May 85 12:30-EDT from masinter.PA@XEROX.ARPA
Date: 18 May 85 9:30:27 PDT
... As long as an incompatible name is being considered, how about changing
the name? While there's some amusement in having SPECIAL a special form,
the novice may well wonder, "well, what's so SPECIAL about them?". Guy
was careful to call them DYNAMIC in the book; it sounds like a more
appropriate name for a (different syntax) declaration.
-- DYNAMIC/LEXICAL --
It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL
in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush
SPECIAL (or make it mean something incompatible).
-- *LEXPR --
Can we get a ruling on whether
(FUNCTION (FOO INTEGER &OPTIONAL INTEGER))
is a valid declaration? p159 is very vague on the subject, giving no syntax
restrictions for the arglist components at all. (Only through the limited
fixed-arg example can you even infer that the arglist given should contain
type names and not be the actual arglist used by the function.)
The compiler should be encouraged to complain if it sees
(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
and later sees
(DEFUN FOO (X)
(DECLARE (SYMBOL X))
but should be discouraged from complaining (or should at least be encouraged
to notice the non-fatal nature of the situation) if it later sees:
(DEFUN FOO (X &OPTIONAL (Y 1) (Z 2))
(DECLARE (INTEGER X Y Z))
since in the latter case, the definition is upward compatible with the
It occurred to me that without &OPTIONAL working in FUNCTION declarations,
the functionality of Maclisp's *LEXPR declaration is conspicuously absent.
By the way, apropos of Masinter's comments above, and given that it's useful
to declare something like takes-variable-number-of-args in advance to thwart
forward-referencing problems, it might also want to be possible to declare
that some form, WITH-RANDOM-BINDINGS, is a special form so that
forward-references (which will tend to be fatal errors) to it can be
diagnosed immediately rather than having to wait for the definition to roll
by. I assume this is what he was alluding to about it might have been
more appopriate for syntax declarations, as in
(PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...
-- "Special Operator" vs "Special Form" --
Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point). Certainly,
(COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the
same type so needs its own name. I would like to see SPECIAL-FORM-P made
obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P
introduced as an alternative. In this way, SPECIAL-FORM-P could eventually
be recycled (or flushed from CL proper and re-invented by private applications
that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually,
having the interim compatibility definition be
(OR (SPECIAL-OPERATOR-P x)
(AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))))
wouldn't be so bad either if we could agree to that. That way, people who
order their COND clauses correctly, could start taking advantage of the
recycled meaning right away. In any case, the important point here is that
the "form" / "operator" distinction needs to be made more clearly than we've
been making it.