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


The rationale is now sufficient, and I support

To prevent confusion, thr proposal should address the lambda-list syntax
explicitly.  In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may noit be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.

If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls.  The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list.  Note that the variable must not be a constant, but that the
keyword-indicator may be.

Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.

One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator.  Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user.  If it screws some current implementations, that's
another (weak) reason to disallow this.  I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".

-- Scott