>One possible singularity is that SmallIntegers do not continuously 
>scale from their indexable Large Integer counterparts.  (A two-chunk 
>SmallInteger arguably should have a non-zero size, and perhaps even 
>respond to at: in a manner that would be logically consistent with 
>LargeIntegers that might represent the small numbers).  For example:
>
>	10000000000000 size  			is 6, and
>	(10000000000000 / 1000) size 		is 5, but
>	(10000000000000 / 10000) size 		is 0!
>
>Is it the latter issue, or some subtle performance issue that is 
>driving this change?

A slight follow-up on my previous message.  Many of the earlier 
objections to reducing the range of size to exclude "scalar" 
operators was the inconvenience of having to provide express tests 
for nil, since nil no longer responds thereto.  This raised some 
interesting issues, which I have yet to sort out.

nil is the sole instance of a class called UndefinedObject.  This is 
an interesting characterization, since the name suggests that, 
perhaps except for operations such as "=", "==" and the related 
"isNil", "ifNil" and "ifNotNil," that nil should respond to nothing 
at all.

But it isn't so.  nil *is* an instance of Object, after all, and does 
respond to a number of Object-related messages, in particular: 
"hash," "isLiteral," "fullPrintString," (even clone, although it just 
returns self).

So, nil as a truly undefined object has no pure, sacrosanct, 
theoretical definition, akin to the "bottom" of a denotational 
semantics.  Or does it?  Have we compromised its meaning as an 
undefined object over the years in the interest of producing a 
"practical" system, or just lapsed from time to time, and perpetuated 
the lapses for conveniences precisely of the kinds we saw when 
beloved "size" was removed from the list of "special" message to 
which the sole UndefinedObject would give meaning?

And, as to those objections, does the lack of purity of nil suggest 
that an Undefined object may not be what we need for our most 
"special" object?  In particular, is it possible that instead of an 
UndefinedObject, what is really needed is an EverywhereDefinedObject, 
a construct, call it "top" or maybe "superSelf", which responds to 
each and every message sent to it with, say, itself?

Given my relative newbieness in Smalltalk, and the high caliber of 
computer scientists practicing in this area, I'll presume this has 
been considered and analyzed before before sticking my neck out much 
further, but I'd be curious for pointers on the subject.

In particular, is there a simple, definitive notion of what nil *is* 
(or is not), that would answer the question definitively whether or 
not it should respond to size?  (It would seem, if there were, there 
are examples of other "lapses" that can be found simply by examining 
UndefinedObject.)  Has the idea of "top" been previously considered?