DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: 18 May 85 9:30:27 PDT
    From: masinter.PA@Xerox.ARPA

    ... 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
declaration.

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.