Contents|Symbol Index|Up: Issues|Prev: KEYWORD-ARGUMENT-NAME-PACKAGE|Next: LAMBDA-FORM

Cleanup Issue `KEYWORD-KEYWORDS`

Status: For Internal Discussion
Category: CHANGE
References: LAMBDA (p59), DEFUN (p67), DEFMACRO (p145), FLET (p113), MACROLET (p113), DEFSETF (p102), FUNCTION declaration (p159), :CONSTRUCTOR option to DEFSTRUCT (pp315-316).

Problem Description

Anyone who shadows LOAD, COMPILE, or EVAL is obliged to shadow EVAL-WHEN (although in practice many people forget and this crops up as a bug later on). This issue comes up a lot in embedded systems, such as Scheme which use stylized loaders, compilers, or evaluators.

The lambda-list keywords are not symbols on the keyword package. KEYWORDP is not true of them. Names that begin with & are generally not usable as variables because many compilers worry that names which begin with & but are not on LAMBDA-LIST-KEYWORDS might be unsupported `keywords' or mis-spellings of supported `keywords'.

Proposal (KEYWORD)

Change EVAL-WHEN to use :EVAL, :LOAD, and :COMPILE rather than EVAL, LOAD, and COMPILE.

Change LAMBDA and the various macros which use &OPTIONAL, &REST, &AUX, &BODY, &WHOLE, &ENVIRONMENT, &KEY, and &ALLOW-OTHER-KEYS to :OPTIONAL to use :OPTIONAL, :REST, :AUX, :BODY, :WHOLE, :ENVIRONMENT, :KEY, and :ALLOW-OTHER-KEYS instead.

eg, (DEFUN FOO (W :OPTIONAL (X 3) (Y 4) :REST Z :KEY A B C) ...)

Rationale

Symbols in the keyword package are already unavailable as variable names because they must be bound to themselves.

This change would make the term keyword would be used to denote one fewer concept in the language.

Current Practice

No one does this.

Adoption Cost

Recognizing these ":" names instead of "&" names would be trivial, though would involve numerous small changes throughout most systems, including changes to the parts of the system which are written in Lisp and which use the old keywords in their definitions.

The `keywords' now in use could continue to be supported by any vendors for a while. Such a deviation would technically make an implementation not conform to the standard, but in practice would not be likely to cause any problems if phased out within a reasonable period of time.

Benefits

This would make shadowing of EVAL, COMPILE, and LOAD not have a surprising effect on EVAL-WHEN.

Although this would not completely fix uses of the word keyword throughout the langauge, it would make the use of the term `keyword' considerably more regular.

The "&" character is freed for possible other uses. There is currently an occassional desire to use it as a readmacro character, but the need to have access to these keywords tends to make that impractical because no one wants to write: (defun foo (x \&optional y) ...).

Non-Benefits

The change is cosmetic. It arguably adds no power to the language and might therefore be accused of being gratuitous.

Conversion Cost

Users would have to change a lot of code in a relatively superficial way, but probably a trivial Query Replace operation would suffice with high reliability.

Aesthetics

Usage of the term `keyword' is simplified, arguably improving learnability and simplifying some documentation.

People might differ on whether they think programs will look better.

Discussion

Pitman wanted this change back when CLtL was not yet published but suggested it "too late" for it to be considered. People ask about this issue from time to time, and this is the appropriate time for it to be reconsidered, even if only to be found to be a gratuitous change. Pitman thinks the change would be nice, but is sensitive to the fact that some may balk at the cost of the number of trivial changes it would require.

Less extreme variations of this proposal might include accepting :keywords in addition to rather than instead of &keywords and/or allowing EVAL-WHEN to use STRING-EQUAL rather than EQL to find its `keywords'.

Edit History

24-Nov-87, Version 1 by Pitman