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

in squeak, there is one assymetry in handling names, when used in
array literals:

#(true false nil foo)  = (Array with: true with: false with: nil with: #foo)

instead of:

#(true false nil foo)  = (Array with: #true with: #false with: #nil with: #foo)

i wonder, is such parse rules standartized or belongs only to squeak?

What is correct behavior, you think is?

--
Best regards,
Igor Stasenko AKA sig.

On Wed, Dec 3, 2008 at 2:01 AM, Igor Stasenko <[hidden email]> wrote:
Last time this came up, I believe we established that that's the ANSI
standard behavior.

Avi

Igor,

What would you expect from the following: #(1)? Should it be (Array  
with: 1) or (Array with: #'1')?

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.

James

On Dec 3, 2008, at 11:01 AM, Igor Stasenko wrote:

Hi Igor,

VAST returns true for:

#(true false nil foo)  = (Array with: true with: false with: nil with: #foo)

I'm not sure if it is because that is the ANSI standard behavior or that's just
what it does.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

2008/12/3 James Foster <[hidden email]>:
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.

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) .

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?
Or, what makes 'null' less important (for someone) than 'nil'. A
little bit of discrimination :)

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.

So, how many of such 'literal constants' we may need in future? Or
maybe, if we treat such names as globals, then we won't need to hack
the compiler every time?
And then, obviously #(true false nil) = (Array with: #true with:
#false with: #nil)

> James
>


--
Best regards,
Igor Stasenko AKA sig.

>>>>> "Igor" == Igor Stasenko <[hidden email]> writes:


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

Given the rate of change of 0 per 28 years, probably not many. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Wed, Dec 3, 2008 at 2:45 AM, Avi Bryant <[hidden email]> wrote:
It is, while the second option is the original Smalltalk-80 behavior
(not explicitly discussed in the Blue Book). I believe Squeak used to
behave that way too.

--Vassili

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

> 2008/12/3 James Foster <[hidden email]>:
>> 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!

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

2008/12/3 James Foster <[hidden email]>:
see end of this message.

if you so sure, can you please give me a citation where it explicitly
says about it? Reasoning?
Doesn't smalltalk stands for simplicity?
What is simpler to remember:
- a name found in literal array treated as symbolic literal
- a name found in literal array treated as symbolic literal , except
nil, true, false
?

at least it would be more uniform from parser's POV, to not make
exceptions for these three cases,
as well as simpler to remember.

> 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.
>
sure i can do that. But this is OT.

good point, as for orthodox, but not for me.
An earth is flat, because church says so, any other opinion is herecy :).

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

sure, but i don't see the strong reason why same not applied to 'nil',
'true' , 'false' as well.

>> So, how many of such 'literal constants' we may need in future?
>
> None. The ones defined by the language are enough.
>

A very subjective point of view :)

no, i'm not asserting about the constants like numbers or strings or
symbol literals prepended with '#' because
they are not ambiguous and always mean same regardless the context (be
it in #() or in method body).

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

--
Best regards,
Igor Stasenko AKA sig.

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?

Conclusion: Squeak doesn't follows ANSI standard in this area :)

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?
So, one may indeed , introduce extra names such as null, epsilon,
undefined and it still will be smalltalk!
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.

On Dec 3, 2008, at 7:13 PM, Igor Stasenko wrote:

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.

> Conclusion: Squeak doesn't follows ANSI standard in this area :)

I disagree. Squeak has an implementation-defined behavior where the  
standard specifies no definition.

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.

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

On Dec 3, 2008, at 6:37 PM, Igor Stasenko wrote:

If I understand correctly, you want #(1) to be (Array with: 1). Please  
correct me if I'm wrong.

As you cited, ANSI 3.4.6.6 defines Array Literals to support three  
reserved identifiers.

> Doesn't smalltalk stands for simplicity?

Yes, I think so. It might have been better if Smalltalk did not treat  
other identifiers as Symbols. If you want a Symbol in an Array  
Literal, make it explicit.

> What is simpler to remember:
> - a name found in literal array treated as symbolic literal
> - a name found in literal array treated as symbolic literal , except
> nil, true, false
> ?

I assume that this is a rhetorical question where the expected answer  
is option #1. If you are aiming for the simplest thing, you could just  
have the rule:
- a token that the compiler identifies as a literal (String, Symbol,  
Number, Character)
If we are going to allow names as well, then we have two simple  
choices: (1) treat the name as a Symbol (giving two ways of specifying  
the same thing); or (2) treat the name as an identifier to well-known  
constants. I understand that you would prefer #1 while I would prefer  
#2 since it adds capability. It seems that most implementations take a  
third, more complex approach: (3) allow names as well-known constants  
(true/false/nil), otherwise treat as a Symbol. I agree that option 3  
is more complex. If I were implementing a Smalltalk, I'd be tempted to  
go with #2, and treat other names as errors.

I agree that not have an exception would be easier for the parser, but  
I disagree about what is the exception. The exception is not for the  
three defined names, the exception is an undefined name. They could be  
treated as an error or they could be treated as a Symbol.

I don't think so. You are arguing for extending Array Literals and I'm  
offering an alternative so that you don't have to make Array Literals  
more complex.

I consider language definition to be a type of orthodoxy. If you want  
a different orthodoxy, then you have a different religion/language. I  
don't mind a Reformation now and then, just don't call the Pope the  
Anti-Christ and claim to be Catholic. ;-)

In GemStone, true, false, and nil are actual entries in a  
SymbolDictionary!

>>> So, how many of such 'literal constants' we may need in future?
>>
>> None. The ones defined by the language are enough.
>
> A very subjective point of view :)

Sure, but I'm entitled to my opinion!

But it is ambiguous. What if I wanted #(2) to be the same as (Array  
with: 2 asString asSymbol)? The compiler defines 2 by itself as an  
Integer. The compiler defines nil by itself as a reference to a  
singleton, not as a Symbol. Why should we treat nil differently from  
2? Inside a literal array, we get the thing the compiler would give us.

Igor Stasenko wrote:
> Doesn't smalltalk stands for simplicity?

Yes. But what you are proposing isn't any simpler. It is just different
"special rules" for literal arrays. If you want it "simpler" then you
would get rid of interpreting unbound names in literal arrays as symbols
and rather have them require proper #symbol syntax. In other words,
instead of

   #(1 2.0 true false 'string' foo bar baz)

you would say:

   #(1 2.0 true false 'string' #foo #bar #baz)

in which case you might even be able to get rid of {} since now there is
a perfectly reasonable interpretation of:

    | date time |
    date := Date today.
    time := Time millisecondClockValue.
   ^#(date time)

and the current (static) literal array implementation would be an
optimization for the case of no dynamic bindings in the contents of the
literal array.

Cheers,
   - Andreas

I prefer this.  I like being explicit in what I intended.   Far too  
often I ran across code that never explained what the method or code  
intended to do, and thus, it was nearly impossible to debug later  
because I could not determine if this was a bug, or they were using  
some compiler side effect, or what.

If you want a symbol in an array, declare it as such.

On Dec 3, 2008, at 7:13 PM, Igor Stasenko wrote:

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.

> Conclusion: Squeak doesn't follows ANSI standard in this area :)

I disagree. Squeak has an implementation-defined behavior where the  
standard specifies no definition.

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.

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

> you would say:
>
>   #(1 2.0 true false 'string' #foo #bar #baz)
>
> in which case you might even be able to get rid of {} ...

if my opinion counts for anything, this is what I would like most.
Explicit and homogeneous syntax, while still simple enough. Of course,
we already have a syntax, and we are very likely not going to change
it... given that it is valid syntax today, I'll just start using it :)

    richie

    richie

2008/12/3 Andreas Raab <[hidden email]>:
I am all with you. One way, or another it makes syntax non-ambiguous.
That's all i'm actually care of.
One more reason to do this way is that if you treat any identifier as
symbol in literal array, then you don't have a way to put a nil, true,
false into it.

Or, following your idea, if compiler sees any identifier in array
literal, then array should be built dynamically at run time.
Again, i like it, because it doesn't affect the meaning of
identifiers/names depending on context, so its not ambiguous.

> Cheers,
>  - Andreas
>

--
Best regards,
Igor Stasenko AKA sig.

2008/12/3 James Foster <[hidden email]>:
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.
to me as well :)



--
Best regards,
Igor Stasenko AKA sig.

2008/12/3 Gerardo Richarte <[hidden email]>:
Your opinion is important, otherwise i wouldn't open this discussion
and just do things in a way i like to do without asking anyone :)

>   richie
>
>   richie
>
>



--
Best regards,
Igor Stasenko AKA sig.

On Wed, Dec 3, 2008 at 7:57 AM, Igor Stasenko <[hidden email]> wrote:
FWIW, here is the Newspeak angle:

The traditional Smalltalk syntax of #(...) is not valid in any form.

The way you create arrays, other than explicitly talking to Array, are
the braces which work essentially the same way as in Squeak. Except
that Newspeak allows implicit receiver sends that are module-scoped,
meaning one could write

   {null. epsilon. #foo. true. nil}

where the first two elements are implicit receiver sends. The methods
null and epsilon returning a message-eating Null and the Epsilon
singleton do not necessarily have to be implemented by the receiver,
they can also be provided by the module that contains all the code
that wants a special treatment of such "literals". In fact, that would
be the right way to architect the null and epsilon use cases.

Cheers,

--Vassili