Re: Issue: IGNORE-VARIABLE (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 8 Feb 89  10:56:57 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    ... I agree that this is a convenience which is often used, but I am less
    sure about whether it is good programming practice. ...

One good metric of whether it is a good programming practice is whether
it ever leads to trouble. Do you ...
 - have any bug reports on file from people who were caught by
   it unaware and asked to have the feature removed.
 - have any instances of real code that uses IGNORE where you felt
   the writer's intent would have been clearer if he'd done something else?
I think most of the examples of using IGNORE that I've seen are very tasteful.
Things like (MAPCAR #'(LAMBDA (IGNORE) (GENSYM)) VARS) to construct a list
of temporary variables in a macro is ultimately more readable, I think,
than (MAPCAR #'(LAMBDA (VAR)
                 (DECLARE (IGNORE VAR))
                 VAR)
             VARS)
since the latter conveys no more information in some people's coding style.
(If I call a list of vars <name>S, it means that the elements will be <name>.)
All the long form ultimately does is to force me to use up three more screen
lines because (as a matter of personal policy) I try never put multiple forms
in an implicit progn on the same line. I assert that anything that gratuitously
loses me screen lines makes the program less readable. The issue is only
whether this is a case where the loss is gratuitous.

Already you cannot choose variable names in Common Lisp with no
regard to how those names were defined. If you do, you'll trip over names
like MOST-POSITIVE-FIXNUM. (Any argument that says you'd never accidentally
choose that one must surely say you'd never choose IGNORE either.) So there's
no big deal about working around the name IGNORE simply by placing it in a list
everyone has to know about of names they shouldn't use without reading doc.

Beyond that, I claim, it's just a matter of "are you going to provide the user
what he clearly wants". The only rational counter-argument (I believe) is not
an aesthetic one because the person making that argument has no leg to stand on.
There is a somewhat rational argument that you're just tired of adding little
features that let users "get what they want" and you just want to say "tough!
i've given you a lot of things. what you're asking for is reasonable but the
cost in terms of address space or my time to implement it or whatever is too
high and i will not give it to you."  This argument was used, for example,
in rejecting CONJOIN, DISJOIN, etc. Given that you acknowledge the convenience
factor, however, that argument is weakened dramatically.

As an aside, the aforementioned metric cited above -would- suffice to show why
looking at the variable's name (independent of package) is not acceptable, since
I can cite actual bugs in real programs that have come from having gensyms with
names like "IGNORE" -- due to doing (MAKE-SYMBOL (SYMBOL-NAME USER-VARIABLE)).
Flexibility to use the same name in uninterned symbols or shadowed symbols in
order to dig one's way out of the attached semantics of a particular symbol is
fundamental to the whole concept of the package system. However, within a 
particular module or package, where use of the package presumably means that
it is a given that the user understands its workings, I think matters of
convenience should be catered to.