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

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