Hi David

At least you did not insult me so this is a good point. (But I was expecting
so from you ;))

 I really like how people react to simple design language questions. May be
I'm abrupt but the discussion worth the bandwidth ;)
 
> The construct is useful and widely used.
Widely in which code????
Where? more than OrderedCollection?

I developped a lot of stuff in VW and never found the need to have {}.



> If it has definitional and
> theoretical problems, then certainly look at how to fix those; but let's not
> discard a useful construct.

But I wish I could send you the kind of code you can write with {} believe
me this is really ugly. So some people will say that this is the case with
everything and the discussion will end.


I thought that Smalltalk was looking for simplicity.
So or we should have a way to describe macro-expansion or remove them!

***The next paragraph is provocative so read before replying ;)***

Having private methods and attributes is useful too. Sometimes I would like
to do real design in Smalltalk.
Having operators is useful too, I would like to have operators too because I
prefer to type 
    2 + 3 * 6 than 2 + (3 * 6)
and because this is MATH and MATH are right!

I hope you see my point.

I like the simplicity of Smalltalk and I'm ready to pay the price to
use convention for expressing private, dealing with operator by hand....
I like simplicity but I do not like this #{} because this is against the
simplicity and ad-hoc!!!

When I checked me code I can tell you that I have much more ordered
collection than array still there is no construct.
So I would really like to have one too!!!!!!!!
may be {{}} could be good.

So the real question is should simplicity be conversed or not.
Is it worth to have caseOf: in Object and all these BraceNode in the
compiler, why do we need that?

I was wondering if { could not be like @

we could write Array { 1 at 1; { 1 at 2
I'm not sure that this uglier than
#{ 1 at 1 . 1 at 2} 

because at least this is a message send without special rule


> 
> 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 was not serious dave.
I do not want {#[]}

#[] is enough for me. I never use it!

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

I agree with that. I tend to start with OC and then convert them as much as
possible into Array.

> 
> Dave