Dan wrote:

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

Stefan replied:

>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 
abbreviated
     as '<datum>

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

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
>
>#,(#answer ,(6*8))
>
>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 
expressions).



     -- tim