URGENT RESPONSE REQUESTED!!!!!

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

For the record, here is my position on #f and () ...

I strongly support any resolution to this controversy which leaves all
implementations required to do the same thing.  I believe it is a grave
mistake to leave this aspect of the language unspecified.

It is my strong belief that -either- the language should accept only
true or false as truth values (hence negating the concept of `predicates
with useful return values like MEMBER') -or- the language should have 
(either explicitly or implicitly) a true-p predicate which is defined on
every object in a portable way.  Truthity/falsity are so fundamental a
concept in a computer language that it is a severe mistake to leave this
issue an open one.

It will be a major ongoing source of portability problems if you
standardize on making either behavior permissible.  While there may be
some people hurt by the change in the nearterm, the longterm benefit of
having the entire community agree and letting them get on to disputing
more important matters will be worth it.

In fact, I do not believe there is a definite right or wrong in this.
I can see value in both positions.

The ability to `pun' on false/empty is, at times, valuable and not
without merit.  However, if this pun is not portably available, it is a
dangerous weapon because puns are subtle and easy to overlook in a
porting process.

Likewise, the ability to speak unambiguously is also, at times, a value
tool.  So I can respect a decision to make these two separate.

My overriding feeling as I continue to monitor the Lisp and Scheme design
discussions is that a characteristic property of Lisp (that distinguishes
it from Scheme) is a willingness to permit considerably more punning than
the Scheme community would feel comfortable with.

Consequently, while I would probably argue strongly that CL should maintain
this ambiguity in a portable fashion (and I disagree with GLS that this
is a clear mistake), I do agree with what appears to me to be tha majority
of those in the Scheme community that the right thing for Scheme is to
eliminate this ability to have an ambiguity on this issue.

Finally, I note that it's hard to undo something once it makes it into a
standard, and I really think that if you're gonna ultimately do it (and
the Scheme community--even some of those who oppose the change at this time--
seems to see itself in transition toward ultimately doing it), doing it
before you standardize is an exceptionally good thing to do.  It's one less
frame to keep on the continuation `stack' for the design of Scheme--one
less thing to have to remember to do the next time around.

Ok, so the last paragraph wasn't final, one more point:  I think a standard
is more powerful if it really achieves consensus.  If you really don't agree
on something and so you write the disagreement into the standard, then you
confuse and irritate people who think that `adhering to the standard' means
that your code runs portably.  Users of CL found this out in spades the hard
way.  The more things you can out-and-out agree upon, the stronger a position
your standard will have.  So this is yet another reason to agree to agree.

My position in summary:
  - I strongly support making #f and () required to be distinct objects.
  - I would happily support making #f and () required to be EQ objects
    as a fall-back.
  - I strongly oppose any wording permitting implementations to diverge
    on this issue.