>>Did this ever get resolved?
>
>I don't think there was a final resolution on it, but this question 
>raises the larger question of Pink plane vs. Blue plane.

[I've written the following in the first person, but I think my thoughts
on this issue are pretty much shared by the whole Squeak team...]

REGARDING NIL AND #NIL
I must plead simply that I'm trying to handle bigger problems in getting 2.2 out.  My feelings are enough in conflict, and the issue is small enough, that I'm not planning on taking any action on this in 2.2.  If you're interested in my process, here's the raw data from my perspective.

1.  I still consider the original literal spec to be simpler and cleaner, and therefore better.  I think the change to evaluating true false and nil fixed something that was not broken.  I'm not sure I want to do that in Squeak.

2.  I can see how it can be convenient to have this feature in some cases and, as I have said, other things being equal(!), compatibility with the ANSI standard (or with other things in the real world) is a plus.

3.  The inline evaluation approach (ST-76's '->(' character, or Tim's ##), is the obvious more general solution, but I just haven't decided whether this is worth its weight, what the best syntax would be, etc.


THE BIGGER ISSUE
As you (may) know ANSI compatibility is of no importance to me, *except* that I know it affects the synergy of this community with the larger Smalltalk community, and that *is* important to me.

A possible process for moving forward here would be for "a few good Squeakers" to step forward and work together to propose some reasonable set of changes that would maximize ANSI compatibility, while minimizing any detriment to Squeak's current direction.  What I have in mind is a sort of "10 most wanted" changes rather than a massive overhaul.  In the context of such a reasoned process, I would probably not stand in the way of changing the treatment of nil in literal arrays (though I might still roll my eyes ;-).

This is probably a good time for such an undertaking.  It is likely that we will make a significant blue-plane departure 6 months or a year down the road, but so far we have been able to accomplish most of our goals working within the system and not changing the language a great deal.  I am hoping that faster execution, and better access to native code (more about this later) will soon be a part of Squeak, and it would be nice to somehow reach a point of maximum value as a "workhorse Smalltalk" before we blast off into some more incompatible realm of "Principia Mathematica meets Multimedia."

So, maybe folks would like to propose their "10 most wanted" changes for compatibility, and/or announce their willingness to work together over the next month or so to assemble such a package.  My role would be limited to reviewing suggestions and code, and coordinating an orderly progress of code updates.

 	- Dan