nil or #nil?

Stefan Matthias Aust sma at kiel.netsurf.de
Mon Aug 24 17:40:13 UTC 1998


Dan & Tim,

>Right now, the rule for what #() does is pretty simple.  Part of the
>Smalltalk design approach is to minimize the number of rules wherever
>possible, even if this means it doesn't always provide the absolute
>most convenient result.

I hate to contradict the inventor of the language, but the current rule for
literal arrays is more difficult than needed. Why are symbols represented
differently inside literal arrays than outside. IMHO, the rule should be
that #(a b) is an error and only #(#a #b) is permitted.  This would allow
one to simplify the BNF-rule for literals arrays as

literalArray = "#(" {literal} ")".

where

literal = number | "nil" | "true" | "false" | 
   symbol | char | string | literalArray | byteArray.

And on Tim's argument, that if nil should be nil and not #nil because
literal arrays don't evaluate self-evaluating objects, then #( 1 ) at: 1
would have to answer the symbol #'1', not the small integer 1.

I think, nil, true and false should evaluate as expected to nil, true and
false. All, VW, VA and Dolphin (probably also ST MT and ST/X) follow this
rule.

You cannot evaluate self or super (or thisContext) inside literal arrays,
because they aren't literals but pseudo variables.  

It might be interesting to be able to unquote some parts of a literal
array, as you could do in Lisp, however. Something like

#,(#answer ,(6*8))

which would answer #(#answer 48)...


bye
--
Stefan Matthias Aust  //  Are you ready to discover the twilight zone?





More information about the Squeak-dev mailing list