Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    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.

Thanks.

    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.