[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 12 May 87 14:56 EDT
- In-reply-to: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Date: Tue, 12 May 1987 10:27 EDT
From: "Scott E. Fahlman" <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 not be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
I was using "non-positional-argument-name" where you used "keyword-indicator".
We have to do something about the terminology. I like "argument name" a little
better than "keyword indicator", although the former has the problem that people
might confuse it with "parameter name", since experience has shown that it's
virtually impossible for anyone to remember which are the arguments and which
are the parameters.
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.
I agree with this, except that the syntax actually has two parentheses,
i.e. ((keyword-indicator variable)), to distinguish it from (variable default).
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
We can take "lambda-list-keywords", which aren't "keyword-symbols" either,
as a precedent.
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".
I don't care about NIL being allowed or disallowed. As a language
designer, it seems like a weird restriction to disallow it, even though
there is no earthly reason to use it. As a commercial vendor, I won't
complain if we don't have to fix the bug that we currently disallow it.
I'll defer to anyone who has a strong opinion about this.