[squeak-dev] [Question] nil, true, false in array literals

James Foster Smalltalk at JGFoster.net
Wed Dec 3 17:07:46 UTC 2008


On Dec 3, 2008, at 4:57 PM, Igor Stasenko wrote:

> 2008/12/3 James Foster <Smalltalk at jgfoster.net>:
>> Igor,
>>
>> What would you expect from the following: #(1)? Should it be (Array  
>> with: 1)
>> or (Array with: #'1')?

You didn't answer my question!

>> I think that the assumption is that you should be able to include any
>> literal constant (including SmallIntegers) in a literal constant  
>> array. I
>> think of #(foo) as a shortcut for #(#'foo'), where the second form  
>> is more
>> explicit. If you want to avoid the ambiguity, then always be  
>> explicit when
>> you want a symbol.
>
> Well, the point is, that i look differently at such names. I don't
> treat them as literal constants, but as names which globally bound to
> some object.

If you are using the Smalltalk syntax of #(), then you should learn to  
look at true, false, and nil as literal constants, because that is  
what the language definition specifies.

> And i can explain why.
> Suppose i want to introduce a class(es) to work with ternary logic:
> 'true' 'false' 'unknown' .. or whatever.
> Does it makes an 'unknown' name less privileged than 'true' or
> 'false'? So, what do you do in this case? Introduce a new 'literal
> constant'? Otherwise you'll have an issue with #(true false unknown) .

Do you want #(true false unknown) to return three symbols? If so, then  
be explicit: #(#'true' #'false' #'unknown').

If you would like an Array constructor that evaluates expressions at  
compile time, then use a different language syntax. In Squeak, you may  
use the following:
	{true. false. unknown}
If 'unknown' is bound to an object, then it will work, otherwise you  
will get a compile error.

> Another variant and same question: Some of us using a Null class to
> make use of message eating nulls.
> Now, if i want to return null, can i introduce a 'literal constant'
> named 'null' as well?

Not without changing the language.

> Or, what makes 'null' less important (for someone) than 'nil'. A
> little bit of discrimination :)

'null' is less important than 'nil' because 'null' is not part of the  
language.

> Another guys can come and say: hey, i'm a matematician, and i want a
> 'literal constant' named 'epsilon' , so lets modify compiler to
> resolve it as a sole instance of Epsilon class.

Even easier would be to have a 'global constant' named 'epsilon':
	Smalltalk at: #'epsilon' put: Epsilon new.

> So, how many of such 'literal constants' we may need in future?

None. The ones defined by the language are enough.

> Or
> maybe, if we treat such names as globals, then we won't need to hack
> the compiler every time?

To treat something as a global, add it to Smalltalk, and the compiler  
will find it. No compiler hacking involved.

> And then, obviously #(true false nil) = (Array with: #true with:
> #false with: #nil)

Again, are you expecting #(1 2) = (Array with: #'1' with: #'2')? That  
would probably surprise a lot of people and break much existing code.

>> James
> -- 
> Best regards,
> Igor Stasenko AKA sig.

James




More information about the Squeak-dev mailing list