nil or #nil?

Dan Ingalls DanI at wdi.disney.com
Sun Aug 23 18:29:35 UTC 1998


Michael -

I'm mildly opposed to the change you recommend.  [The rest of this message is by way of explication, and not in any way "aimed" at you]. 

Right now, the rule for what #() does is pretty simple.  Part of the Smalltalk design approach is to minimize the number of rules wherever possible, even if this means it doesn't always provide the absolute most convenient result.

To convert 'nil' in a literal array to a real nil instead of a symbol would be a special case, and would leave someone who expected the symbol just as confused as you were, though in the opposite manner.  Plus, if we did it for nil, should we not also do it for true and false?

My feeling about this is that "The road to hell is paved with good intentions".  To wit: someone in another Smalltalk decided to make it "more friendly" in this regard, and then code was written using that feature which wound up causing you much confusion.

If you want some alternatives, then I would consider...

1.  Table _ #( (-1 -1 ) 2 3) copyWith: nil.
....the no-frills approach.

2.  Table _ { {-1. -1}. 2. 3. nil}.
....at least if someone ports it, they'll know it needs to be converted from Squeak.

3.  Table _ #( (-1 -1 ) 2 3 ##(nil)).
....I'm NOT proposing ## as the operator that means evaluate (a sort of un-literal mode), but I AM saying that if we must have a way of putting values in a literal expression, then let us
	a)  make it explicit, and
	b)  make it general.
[Historical note: ST-76 had just such a construct -- it had a special character (typed as ctrl-openParen) that looked like '->(' and meant "the value of this parenthetical expression" in a literal.  Needless to say, that feature was not felt to carry its weight when the ST-80 standard was defined]

	- Dan

P.S.  By the way, I'm glad to hear you're porting T-Gen.  Hope it goes smoothly.

>I'm playing with porting T-Gen.
>In doing so I ran into the following interesting problem.
>The parse tables in T-Gen are initialized using a construct like so (you
>can run this, if you like, and follow along):
>
>Table _ #( (-1 -1 ) 2 3 nil).
>Table inspect
>
>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?
>
>        mkd





More information about the Squeak-dev mailing list