>In furthering my understanding of Squeak I came across the fact
>that
>
>( #( nil ) at: 1 ) ~~ nil.
>
>evaluates to true.
>
>The nil inside of the literal array is interpreted not as a nil,
>but as the symbol #nil. I see this behavior in Squeak 2.3 with
>all the latest updates downloaded and installed. Is this correct
>behavior?

Dave -

In short, yes.  It is the way Squeak is supposed to work, and the way all Smalltalk-80s worked originally, following the simple rule that identifiers in a literal array get turned into symbols -- period.

You may want to stop here  (8-)...

Some people expect, and some Smalltalks provide, special treatment for nil, or for nil, false and true.  There was a loooooo......ooooooong discussion about this on the SqueakList beginning 8/23 of last year under the heading, "nil or #nil?".  Everyone has good reasons for their differing positions on this topic.

Here are the reasons for the status quo...

1.  It's simple.

2.  There are other ways (though not quite as brief) to build arrays containing nil (and true and false and any other defined variable or expression).  These include the {} construct, as well as Array with:with:, copyWith: and so on.

3.  If we (oops -- sorry, this means me ;-) wanted to introduce evaluation into the construction of literal arrays, we would do so in a manner that included general expressions, and probably arbitrary embedded objects.

4.  We (oops -- ditto) don't consider this to be broke, so we ain't going to fix it until there is rampant agreement on the issue (there wasn't last August), or some other compelling reason.

There is a (dormant, I feel) project on this list to propose a number of changes that would enhance ANSI compatibility without adversely affecting other positive attirbutes of Squeak.  The treatment of #(nil) would naturally be an item on such an agenda.  If a serious proposal were to emerge, it would constitute a possible compelling reason under (4).

	- Dan