>Table _ #( (-1 -1 ) 2 3 nil).
>
>Apparently, the Smalltalk that T-Gen was written for (?) treats nil as a
>special case. But for Squeak, (Table at: 4) == #nil (not nil). This was
>pretty tricky since it looks like a nil when you print it out. If you
>inspect it, however, you see that it is an array with three elements.
>
>I'm thinking that this is so confusing that Squeak should adopt the
>behavior of recognizing 'nil' as a special case inside of a constant array.
>
>Any thoughts?

I think it is correct the way it is in Squeak -- literal vectors are 
built from unevaluated literals, where all literals are "self-evaluating" 
(evaluate to themselves).  The value of the symbol nil is the symbol nil, 
which is different from the standard value nil (the sole instance of 
UndefinedObject).

Making a special case for nil here starts one down the slippery slope of 
mixing up symbols and variables (values).  What about #true and #false -- 
would you expect them to exist in the literal vector as symbols or 
Booleans?  What about symbols which match existing entries in the 
SystemDictionary, such as classes?

In fact, making such a change would break some existing code.  For 
example, TMethod>>isSubstitutableNode:intoMethod:in: uses exactly this 
construct:

     .
     .
		(#(self true false nil) includes: var) ifTrue: [ ^ true ].
     .
     .

Here the the code is expecting the literal vector #(self true false nil) 
to be the vector of symbols #self, #true, #false, and #nil.


Squeak already has braceNodes to allow easy definition of evaluated 
arrays, for example:

     Table := { {-1. -1}. 2. 3. nil}.

More portably, one can explicitly build the array:

     Table := Array
          with: (Array with: -1 with: -1)
          with: 2
          with: 3
          with: nil.




     -- tim