>> I think we should be careful on this slippery slope...as you point out,
>> there is a delicate balance between simplicity and purity.  Many
>> languages have been ruined by adding constructs that were meant to make
>> things more convenient but sacrificed consistency.  I think this was
>> Stephane's point actually.  These constructs usually make a language
>> more convenient for those with a lot of experience in the language, but
>> much more difficult for people new to the language.  If you need proof
>> of this, just look at the recent thread titled "Storing and Retrieving
>> Points."
>> 

This was my point even if I expressed so badly. Sorry for that.
I do not knwo who wrote that but YES YES YES. This is what I wanted to say.


> This is where the discussion should be!
> 
> I'd actually rather get rid of #() than {}.  #() is the confusing one,
> and it's really only there for speed.  Yet, the compiler could easily
> check whether a {} instance can be converted to #() internally....

As daniel mentioned it this is indeed an interesting alternative. At the end
we would have only one construct.
> 
> Admittedly, we could  even gid rid of both of them, and not be too bad
> off.  They sure are convenient sometimes, though, especially for hacking
> around in a workspace.
> 
> 
> By the way, to maintain the ability to interchange with ANSI, we can
> take advantage of Stephan's note and expand the construct on fileout as:
> 
> (Array new: 10)
> at: 1 put:  foo;
> at: 2 put:  bar;
> ...
> yourself
> With a moderate effort, this construct can even be changed back when
> code is read back in.
> 
> 
> -Lex
> 
>