Dana Anthony wrote:
> 
> Dwight Hughes wrote:
    ---snip---
> >
> > In this light, nil, true, and false are literals - but so are #nil,
> > #true, and #false -- the problem right now is that nil ~~ #nil, true ~~
> > #true, and false ~~ #false, which is a bit counterintuitive. Would it
> > outrage anyone to consider nil, true and false to be syntactic sugar for
> > #nil, #true, and #false?
> >
> > -- Dwight
> 
> You bet people would be outraged.
> Mainly because of a simple fact:  #nil, #true, and #false are instances
> of Symbol.
> 
> nil is an instance of UndefinedObject; true is of True and false of
> False.

Well, I consider nil, true, and false to all be symbols -- in the
generic sense -- and consider the schizm between them and instances of
Symbol to be an design artifact forced upon Dan and crew to compensate
for the single inheritance class structure and the limiting of method
dispatch to the class of the receiver (instead of the receiver itself).
So Dan waved his keyboard and said: "Let there be true and false and
nil, and let each take unto itself a class and a place in the hierarchy,
by which each shall be known to all." I understand your objections
within the present Squeak/Smalltalk design, but I also find that having
#nil, #true, and #false be meaningless symbols with no correspondence to
nil, true, and false to be rather ugly.

> How can a symbol be == to an undefinedObject or a boolean?  It cannot.

That depends on how badly I want to win this debate ;-).

> That's just not object oriented :) :)

Ever hear of multiple inheritance? A dandy concept for situations like
this (and for diverting attention from the topic at hand). (For those
interested in such things, "closure based" multiple inheritance (as
implemented in Idol - an object-oriented variant of Icon) is worth
checking out: http://www.cs.utsa.edu/research/idol/closure.ps.)

-- Dwight