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


Status:	      I edited this to put some things in different sections
(Aesthetic arguments under aesthetics, cost of converting existing code
into that section) and added some wording to meet Scott's "to prevent

		Ready for release? [Use ballot]

References:   Lambda Expressions (CLtL pp60-64)
Edit history: 20-Apr-87, Version 1 by Moon
	         29-Apr-87, Version 2 by Pitman
              11-May-87, Version 3 by Moon
              29-May-87, Version 4 by Masinter

Problem Description:

CLtL says that only keyword symbols can be used as non-positional
names in &key parameter specifiers.

As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)

Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]


Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.  That is: 

If, following an &key, a variable appears alone or in a (variable
default-value) 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 non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list.  The
keyword-indicator can be any symbol, not just a keyword.

Test case:

    (FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))

(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"


The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.

The desire for non-positional arguments whose names are not keyword
arises when the set of non-positional arguments accepted by a function
the union of the sets of non-positional arguments accepted by several
functions, rather than being enumerated in a single place.  In this
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.

One example of a Common Lisp application that requires this capability
the draft proposal for an object-oriented programming standard (CLOS).
It will
have generic functions that accept non-positional arguments and pass
them on
to one or more applicable methods, with each method defining its own set
arguments that it is interested in.  If this proposal is not adopted,
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.

A second example of a Common Lisp application that requires this
is private communication channels between functions.  Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
This could be done without fear that the use of EXPLICIT T would
some keyword in keyword-value-pairs, since the only way that could
happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user
programming explicitly in the FOOLAND package, either of which is an
admission of willingness to violate FOOLAND's modularity.

Documentation Impact:

The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
the impact of the proposal.

  Change wording which refers to non-positional arguments as being
  by keyword symbols to simply refer to those arguments being introduced
  symbols. For example, in the middle of p.60, the sentence:
    ... each -keyword- must be a keyword symbol, such as :start.
  would become
    ... each -keyword- must be a symbol.
  Also, the word "keyword" in the first complete sentence on p.62 would
  be changed to "symbol" for similar reasons.

  Add extra wording on p.60 to explain that by convention keyword
  are normally used as non-positional argument names, and that all
  built into the Common Lisp language follow that convention.  A
  manual might or might not choose to describe the circumstances in
  it is appropriate not to follow this convention.

  Add examples to illustrate this behavior. For example, on p.64 the
  following examples might be added:

    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    => (1 2 6 NIL)

    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    => (1 2 6 NIL)

Current Practice:

We do not currently know of an implementation that enforces the
that this proposal seeks to remove.

Some implementations have bugs that prevent NIL from working as a
argument name, but allow all non-NIL symbols. (One Symbolics version
was checked had this bug.)

Adoption Cost:

Some implementors might have to rearrange their error checking slightly,
but it should be very easy.


This will help with the object-oriented programming standard, among

Conversion Cost:

None--no existing programs will stop working.  


The restriction of &key to only keyword symbols is arbitrary and

There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.

In any case, users who do not want to use the extended functionality
can generally avoid it.


Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.

If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.

Some members of the cleanup committee would just as soon exclude NIL as
a legal keyword-indicator. It might catch some errors, but is possibly
otherwise an odd restriction. Disallowing NIL would reduce the adoption
cost for some implementations.

The cleanup committee supports this change.