Why we should remove {} from Squeak

danielv at netvision.net.il danielv at netvision.net.il
Mon Oct 1 12:12:17 UTC 2001


Hi Stef.
I present ;-) - 
{} - The argument from simplicity.

I expect things in Squeak to dynamicly calculated, unless explicitly
cached or immutable.
#() 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.

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])

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




More information about the Squeak-dev mailing list