nil or #nil?
tim at jumpnet.com
Tue Aug 25 01:51:04 UTC 1998
>>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...
I think the BNF simplification argument is a reasonable one, but I view
the current semantics a bit differently.
The Scheme programming language defines literal vectors and lists the
same way Squeak currently does, where the description is:
(quote <datum>) evaluates to <datum>. <datum> may be any external
representation of a Scheme object. (quote <datum>) may be
'a => a
'(a b c) => (a b c)
Note there is no quoting "inside" the list, as the list itself is the
entity being quoted, and is written just like its external representation
is printed. Likewise in Squeak,
#a => a
#(a b c) => (a b c)
>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.
Well, #1 answers the SmallInteger 1, not the Symbol 1. Again, the same
as in Scheme
(integer? '1) => #t " '1 is the same as 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
The argument for compatibility is also a somewhat strong one, but I still
think it comes at the expense of "cleanliness" and simplicity.
>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
>which would answer #(#answer 48)...
This sounds much like Dan's description of ->(
I think it would be somewhat useful as well, although the brace notation
already handles this (i.e. we have a way to create an array of
non-evaluated literals, and a way to create an array of evaluated
More information about the Squeak-dev