Re: User survey

[Todd Allen <Allen@YALE.ARPA>]

1.  I can't think of a good reason to redefine QUOTE, but I understand
the resoning behing your question.  The concern is valid, but I think
you ought leave things alone.  Defining 'FOO to be a synonym for (QUOTE
FOO) means that the behavior of ' is well defined, even if QUOTE is
redefined.  People who have compelling reasons to separate ' from
QUOTE are likely to understand (1) that is is required and (2) how
to do so (i.e.,move the old definition of the QUOTE special-form to
a new name and redefine the read-time syntax of ' to use the new name
of the original QUOTE).

2.  Having fixed canonical truth values is very useful and saves us
all from some very hairy problems.  In order to allow canonical truth
to float, ALL routines (e.g., predicates) must evaluate some "global"
variable to obtain the truth value.  Since this variable can be shadowed
the problem now arrises as to exactly what value will be returned
by predicates.  Also, what safeguards are there to prevent users from
accidentally assigning the canonical false value to the the variable
that is supposed to hold the canonical truth value?  It is real easy
to get burned in the interpreter, but early binding of T in the compiler
protects compiled code (to some degree).

I don't have code that directly depends upon truth being #[SYMBOL "T"],
but I do have code that depends upon BOOLEAN? working correctly at
all times.  I can't see how BOOLEAN? can be made to work correctly
if truth is defined to be the value of some shadowable variable.

In all honesty, I think there is something to be said for making the
variables that contain the canonical truth and falsity values be
non-settable and non-shadowable.  I have yet to ever find a valid
use for redefining either, and the danger of accidentally redefining
them is ever present.  I did once accidentally set NIL to some non-null
value, and you wouldn't beleive the havok that resulted from this
carelessness.  What you are proposing would significantly increase
the chances of total disaster.

3.  I'd like to see LET and LABELS have the same syntax.  There are
many times when I use labels rather than (LET ((X (LAMBDA ...))) ...).
Besides, LABELS type syntax allows the compiler to generate nicer
messages about these functions.  Initially, I was put off by
DESTRUCTURE, but I am beginning to realize that explicitly flagging
this construct makes a lot of sense, and it does not occur all that
frequently (in my code).  Similarly, multivalue return ought to require
special syntax.