On 8 févr. 05, at 14:11, Bert Freudenberg wrote:

> Am 08.02.2005 um 12:00 schrieb stéphane ducasse:
>
>> yes.
>> this is what I thought after.
>> But this was an interesting example of the limit of syntactic sugar.
>
> Why would you think so? #printString is supposed to deliver a readable 
> representation, not an executable one, that's what #storeString is 
> for. It's not a limitation of {} at all.

No because for some objects: true, false, character, symbol, string, 
1,2 the store string representation is equals to the input form and {} 
breaks this rule. Array storeOn has to be written Array new: ...add: 
because an array can only contain literals but {} is different

Imagine that {} would create an instance of DynamicallyCreatedArray A 
subclass of Array, then collect by using species would return object of 
this class and with an adequate printOn:
we could close the loops: ie using a textual representation understood 
by the compiler to manipulate the object. No need to know that we 
should have a special storeOn: method on array.

Therefore with a simple fix {} would be much better integrated than it 
is now.
I think that this is related with my lisp background
as in lisp
	1 evaluates in 1
	true evaluates in true
	'klk;lk' evaluates to 'klk;lk'
	
We could have { 10 at 10 .  20 at 20 } prints as { 10 at 10 .  20 at 20 }
and #(10 @ 10 ) prints as #(10 @ 10 )

This way the programmer does not have to think that {} is a shortcut or 
a hack
and know ok {} is just a textual input for the same objects.

So why this solution is worse than the current one?

Stef