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

Igor Stasenko siguctua at gmail.com
Wed Dec 3 20:02:42 UTC 2008


2008/12/3 James Foster <Smalltalk at jgfoster.net>:
>
> On Dec 3, 2008, at 7:13 PM, Igor Stasenko wrote:
>
>> Its quite interesting what smalltalk ANSI draft says about it:
>>
>> ----
>> 3.4.6.6 Array Literals
>> An array literal is a sequenced collection with numeric keys which may
>> contain any number of other
>> literals.
>> <array literal> ::= '#(' <array element>* ')'
>> <array element> ::= <literal> | identifier
>> The value of an array literal is an object that implements the
>> <sequencedReadableCollection>
>> protocol. The elements of an array literal can consist of any
>> combination of literal forms. If an
>> identifier appears as an <array element> and it is one of the reserved
>> identifiers nil, true or false
>> the value of the corresponding element of the collection is the value
>> of that reserved identifier. The
>> meaning is undefined if any other identifier is used as an <array
>> element>. If an <array literal> has
>> no <array element>clauses the collection has no elements.
>> ----
>>
>> So, as i understood, if meaning for any other identifier, except nil,
>> true, false is undefined - then parser should produce the syntax
>> error, isnt?
>
> As I read it the meaning is "undefined." "Undefined" means that ANSI does
> not define the behavior. If ANSI wanted an error, it could have specified an
> error. If a behavior is undefined, then the implementation is free to choose
> any particular behavior. In the case of Squeak, and most Smalltalks, 'any
> other identifier' is treated as a symbol for convenience and to reduce
> keystrokes.
>

You are right here. So, we discussing about, which way is better to
define this undefined piece :)
For most of devs its a minor details. But i'm currently making own
parser and i don't want to blindly put stuff into it without clear
understanding why it done in this way, and consider alternatives.

>> Conclusion: Squeak doesn't follows ANSI standard in this area :)
>
> I disagree. Squeak has an implementation-defined behavior where the standard
> specifies no definition.
>
>> Next interesting thing in following:
>>
>> 3.4.7 Reserved Identifiers
>>
>> <snip>
>>
>> Implementations may define other identifiers with bindings that have
>> implementation specified
>> semantics. Any such identifier must be bound in the extension scope of
>> the program.. An explicit
>> definition of such an identifier in any scope supersedes the
>> implementation provided binding.
>> -----
>>
>> as i understood, standard does not says, that given set of reserved
>> identifiers is final?
>
> You are right. Some Smalltalks have implemented 'thisContext' as a reserved
> identifier.
>
>> So, one may indeed , introduce extra names such as null, epsilon,
>> undefined and it still will be smalltalk!
>
> It appears so, but I'd find that contrary to my interpretation of the spirit
> of Smalltalk.
>
to me as well :)

>> But we all know that system dictionary is much better place for them,
>> unless a new name provides a completely different semantics, like
>> thread local storage.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list