Litteral arrays parsing

Wolfgang Helbig helbig at Lehre.BA-Stuttgart.DE
Tue May 23 23:16:38 UTC 2006

you asked:

>Le Mardi 23 Mai 2006 16:42, Noury Bouraqadi a écrit :
>> Hi,
>> A stupid question, why evaluating
>> #("comment") leads to an empty array instead of an array with a single
>> element #'"comment"'?

>This one is a bad behaviour indeed, a side effect of Scanner/Parser internal 
>implementation... (Ascii 30 being used with meaning "end of input").

As long as it is "internal", I can't see anything wrong with it.

>Behind #, i would expect a letter [a-z][A-Z], a string quote ', or an opening 
>parenthesis (. Maybe a second # in Dolphin Smalltalk extension...
>What else does make sense according to Smalltalk formal definition?

According to the syntax diagrams in the Book (choose the book's color from 
blue, yellow or purple), the sharp character may occur as the first character of 
an array constant or a symbol constant. In these positions it is followed by a 
left parenthesis, if it marks an array constant, otherwise it marks a symbol 
constant and is followed by a letter, a special character or a minus character. 
Remember, special characters are the ones that make a binary selector.

Inside a string or a comment, the sharp character may be followed by any of the 
95 graphic characters.

And finally, inside a character constant, the sharp character may be followed by 
any character.

This holds for the language as defined formally by the syntax diagrams, but not 
for the Smalltalk programming language as described informally by the Blue Book, 
where "any character" may occur inside comments, strings and character 
constants, that is not only the graphic characters but ASCII control characters 
as well, like carriage return, horizontal tabulator or record separator which is 

And this again differs from the language as accepted by the compiler in the V2 
image of Smalltalk-80. For example, the ASCII 0 character inside a character 
constant gets you an index error. But this is another thread :-)


Weniger, aber besser.

More information about the Squeak-dev mailing list