[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
|