> I expect things in Squeak to dynamicly calculated, unless explicitly
> cached or immutable.


I like that in fact.

I discussed with VW5i people, they told me that now poolvariable where not
static anymore but they told me that they got some headaches due to the
synchronization required  when accessing them because
code in different thread could access them .

They also rename classVariable into sharedVariables I would loved that in
Squeak ;)

> #() is in violation of that. That's forgivable only because it's usually
> not changed, and filled with immutables - and we do need those often.
> 
> A syntax is by definition a bunch of patterns that specially handled, I
> measure a good syntax by getting good expressiveness with few surprises.
> Theoretically, I'd prefer to see a Smalltalk with no #(), than a
> Smalltalk with no {}, because {} gives more bang for the buck. Only
> reason I see to keep #() (and I may be forgetting something here) is
> speed.

It's fun and make me thinking. I was coming up this afternoon with the idea
that with simplicity a la scheme in mind = purity, writing

Character with: 'a' is not equal to $a
because the first one is always created
the same goes for #() and Array new
but for #{} and Array new we have the same creation attitude.

but with your point of view =
a good caching we could get rid of #() ;) this would be fun.


> Fact is, we also very often need less restricted bunches of stuff to
> start a calculation out, and you should have a reasonable syntax to do
> it.
> 
> So, Stef, a challenge -
> Provide some alternative, that doesn't make this code look stuffy.
> Because it's sure doesn't belong in a suit... ;-)
> Bag new addAll: ((1 to: 5) collect: [:e | Ball colored: {Color white.
> Color blue. Color red} atRandom])

Sure my approach is more verbose and certainly less readable.
> Daniel
> P.S. - come to think about it, what if we do dump #(), use {}, and just
> cache where we need the speed? How bad would that be?
> 
> 
> "David N. Smith (IBM)" <dnsmith at watson.ibm.com> wrote:
>> Stef:
>> 
>> But......
>> I use it all the time. It's a neat idea. Here is code I found by searching
>> all source for #{.
>> 
>> EToyIncommingMessages class>>allTypes
>> 
>> ^MessageTypes ifNil: [
>> MessageTypes _ {
>> self typeKeyboardChat.
>> self typeMorph.
>> self typeFridge.
>> self typeStatusRequest.
>> self typeStatusReply.
>> self typeSeeDesktop.
>> self typeAudioChat.
>> self typeAudioChatContinuous.
>> self typeMultiChat. } ]
>> 
>> HeadMorph>>addSpikyHair
>> | hair |
>> hair _ PolygonMorph
>> vertices: {83 at 3. 81 at 30. 91 at 27. 111 at 23. 97 at 32. 112 at 37. 99 at 45. 114 at 52. 95 at 53.
>> 55 at 43. 10 at 50. 1 at 40. 14 at 40. 8 at 26. 24 at 37. 15 at 11. 29 at 29. 30 at 16. 36 at 30. 41 at 6.
>> 49 at 31. 54 at 8. 61 at 32. 64 at 1. 70 at 27}
>> 
>> 
>> Next is a fragment of a demo. The names Babble, Donut and Marble are
>> humorous, but descriptive.
>> 
>> d := BabbleDonutMorph new largeDonut; name: '- Commons Area -'.
>> d addAllMarbles: {
>> (BabbleMarbleMorph new mediumMarble name: 'Wendy').
>> (BabbleMarbleMorph new mediumMarble name: 'Dave and Archie at home').
>> (BabbleMarbleMorph new mediumMarble name: 'Tom in Minneapolis').
>> (BabbleMarbleMorph new mediumMarble name: 'Mark').
>> (BabbleMarbleMorph new mediumMarble name: 'Big Screen').
>> (BabbleMarbleMorph new mediumMarble name: 'John in the Lab') } shuffled.
>> 
>> 
>> These are just a few examples I picked to show 'interesting' uses of { and }.
>> I found 794 methods in my image that contained at least one ${. A few were
>> commented out C code. Most were from the array constructor. It's used widely
>> and the result of using it makes the code much more readable than 'Array
>> with:'.
>> 
>> The construct is useful and widely used. If it has definitional and
>> theoretical problems, then certainly look at how to fix those; but let's not
>> discard a useful construct.
>> 
>> 
>> At 8:49 +0200 9/30/01, ducasse stephane wrote:
>>> Hi daniel
>>> 
>>> I send it into the mailing list too becuase this is important
>>> 
>>> From a language design perspective
>>> 
>>> #() is necessary because it is compiled statically and cannot not be
>>> simulated by other construct. Storing #() in Stack frame is not really goo
>>> but this is an implementation aspect.
>> 
>> I don't think this is true at all.  #() holds symbols, strings, characters
>> numbers, and in some Smalltalk systems it holds true and false. There is
>> nothing in a #() that you can't write as a literal elsewhere, so:
>> 
>> #( abc 'abc' 4  3.4  $r )
>> 
>> can be written as:
>> 
>> (Array with: #abc with: 'abc'), (Array with: 4 with: 3.4 with: $r)
>> 
>> #() is a great convenience, but it is not absolutely necessary.
>> 
>>> #{} is not necessary because this is shortcut macro-expansion for Array new
>>> add: ....
>>> 
>>> So why having only this one. There is two ways:
>>> or you have a way to describe macro-expansion like in Scheme where you
>>> can define any macro in a clear way (you know the semantic of the stuff
>>> 
>>> or we remove it because why not having
>>> {{}} for Set new add:
>> 
>> This already has a definition: an empty array in an array, like:  #(#()).
>> 
>>> {#[]} for OrderedCollection new....Because I use more
>>> OrderedCollection than array
>> 
>> #[] isn't used in Squeak, but some Smalltalk systems (and maybe the standard)
>> use it as a way of writing ByteArray literals:  #[ 0 255 76 98 4 67 2 ]. We
>> should carefully decide if we want to differ from others in syntax.
>> (Actually, 'we' already have; for some odd reason '#[' is a symbol!  I would
>> have expected to have to write #'[' to get a symbol with a special
>> character.)
>> 
>> I use more OrderedCollection's too, but it was interesting to note that after
>> looking at a couple of hundred uses of {} I don't recall seeing even one
>> message send to convert the array to something else. I think that OCs are
>> widely used when code is building an indexed collection, but rare when the
>> collection is built ahead of time by a literal array or array constructor.
>> 
>>> ... SNIP ...
>>> 
>> 
>> Dave
>> -- 
>> _______________________________
>> David N. Smith
>> IBM T J Watson Research Center
>> Hawthorne, NY
>> dnsmith at watson.ibm.com
> 
>