Cleanup Issue IGNORE-VARIABLE

Status
didn't get to it by Mar 89; withdrawn
Forum
Cleanup
Category
CHANGE
References
IGNORE declaration (p160)

Problem Description

Many users of Symbolics Common Lisp (under Symbolics Genera) have grown used to the variable named `IGNORE' receiving special treatment and have complained that Common Lisp does not offer the same `feature.'

Proposal (SPECIAL-TREATMENT)

1. Define that the variable IGNORE (in the LISP package only) is always implicitly ignored. It is an error to use the variable IGNORE. A declaration of (IGNORE IGNORE) is permitted, but redundant.

2. Permit the variable IGNORE (or any variable declared ignored with the IGNORE declaration) to be a duplicated variable in a binding list.

Rationale

1. Greater syntactic conciseness. This is effectively current practice in some implementations.

2. If only one variable is going to be dignified in this way, it must be possible to repeat it. If it makes sense to repeat IGNORE, it makes sense to repeat any name declared IGNORE.

Test Cases

CLtL Proposed #1: (DEFUN FOO (IGNORE) T) may warn ok #2: (DEFUN FOO (IGNORE) IGNORE) ok is error #3: (DEFUN FOO (IGNORE IGNORE) T) is error ok #4: (DEFUN FOO (IGNORE IGNORE) IGNORE) is error is error #5: (DEFUN FOO (X X) (DECLARE (IGNORE X)) T) is error ok #6: (DEFUN FOO (X X) (DECLARE (IGNORE X)) X) is error is error

Current Practice

Symbolics Genera currently treats all variables with the name "IGNORE" (regardless of package) as ignored variables and complains if you try to use them. It provides no way to turn off the `feature.'

Symbolics Cloe does not special-case variables named "IGNORE".

Cost to Implementors

Small.

Cost to Users

Although the change is technically incompatible, very few programs would be likely to require change, since a name like IGNORE is unlikely to have been used for anything other than an ignored variable.

Cost of Non-Adoption

Some programs would be clumsier to write.

Benefits

Less verbose code in some cases. Existing code in some dialects would not require translation.

Aesthetics

At first brush, some might argue that this makes a bad special case in the treatment of symbols as variables. However, on closer inspection, it's clear that the language already treats some symbols magically:

- Symbols on the keyword package are treated specially with respect to their values.

- Symbols like *PRINT-LEVEL*, etc. have pre-defined special meanings and cannot be bound without knowing their conventions.

- Symbols like NIL and MOST-POSITIVE-FIXNUM have pre-defined values and cannot be bound at all.

The thing which makes these changes palatable is that none of them is based on the symbol's name. As such, anyone unhappy with this treatment can simply make a new package that shadows the symbol and the symbol will be treated normally if that is what is desired.

Discussion

When translating Macsyma from Zetalisp to Common Lisp a few years ago, the use of Maclisp/LispM-style IGNORE was so pervasive that Pitman ultimately just did (PROCLAIM '(SPECIAL IGNORE)) to muffle all the would-be warnings. Except for the situation of duplicate variable names, this is a totally portable solution, but it is -not- efficient.

Some people have suggested that (PROCLAIM '(IGNORE IGNORE)) should work, but others argue that PROCLAIM should not, in general, be assumed to affect lexical references.

Moon and Pitman mildly support option SPECIAL-TREATMENT.

Symbolics Common Lisp users have often expressed a desire to see this feature in portable Common Lisp.

Some Symbolics users have complained specifically about the incompatibility between Symbolics Genera and Symbolics Cloe in their treatment of the variable IGNORE. Although Cloe has CLtL to fall back on for justification, Cloe is invariably seen as the "bad guy" in their reports because it stubbornly keeps them from getting the functionality they want on the basis of what to them seems an irrelevant religious or philosophical concern.

Some people might want to see a symmetric treatment of an ignored variable in SETQ and MULTIPLE-VALUE-SETQ.

Maclisp used to permit NIL to denote an ignored variable. In general this worked out well. The disadvantages to using NIL over using IGNORE are: - The common kind of macroexpansion error where NIL is substituted for a useful value is harder to detect. - There would be a potential conflict between the any meaning for NIL in its `proper role' at the end of a dotted list and any opposing meaning that a destructuring operation (eg, DEFMACRO, LOOP, DESTRUCTURING-BIND) might want to assign to a dotted variable in that position.

Note well: Experience with Symbolics Genera shows that special case treatment based only on the name -- or some substring thereof -- and not also on the package is a bad idea because there is no way to get away from the feature if you don't like it. It is therefore an important aspect of this proposal that only LISP:IGNORE is affected, and that an EQ-test (and not a substring comparison) is the criterion for identifying this magic variable.

Edit History