[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: IGNORE-VARIABLE (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: IGNORE-VARIABLE (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 6 Feb 89 16:51 EST
This was already being discussed under DESTRUCTURING-BIND. I'm
spawning a new issue name to help partition/focus the discussion.
References: IGNORE declaration (p160)
Edit history: 06-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
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.'
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.
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.
#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
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:
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.
Less verbose code in some cases.
Existing code in some dialects would not require translation.
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.
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
- 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
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.