[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Tue, 12 May 1987 10:27 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 11 May 1987 21:59-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
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".