Am 08.02.2005 um 14:53 schrieb stéphane ducasse:

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

Yes. We even have a word for that: literals.

>  and {} breaks this rule.

It does not. This is not a literal, but expressions.

> Array storeOn has to be written Array new: ...add: because an array 
> can only contain literals but {} is different

Array>>storeOn: could easily be written using {}.

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

Actually there is a special storeOn: method in Array already.

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

So what? These examples work in Squeak, too, because they are literals.

> We could have { 10 at 10 .  20 at 20 } prints as { 10 at 10 .  20 at 20 }
> and #(10 @ 10 ) prints as #(10 @ 10 )

Yes, by changing Array>>storeOn: we can have that, as I said.

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

I can't parse that sentence, sorry. {} is precisely a shortcut for 
(Array braceWith: a with: b ...). Or, in it's longer form, it is 
((Array braceStream: N) nextPut: a; nextPut: b; ...; braceArray).

> So why this solution is worse than the current one?

Because nobody bothered generating the brace constructor in the array 
printing/storing methods?

I admit that I also like being able to re-evaluate the print-string of 
an object. However, what would be even better is if you would get a 
reference to the *same* object that was printed. We just do not have 
the right tools for that. An inspector is unwieldy. MorphicWrappers 
probably come closest.

I could imagine adding text attributes to a printed string that 
references back to the originating objects. Selecting a subexpression 
would also select just that part of the object tree. The 
objects->text->compiling->objects transformation is necessarily lossy, 
so by keeping the references we would circumvent this.

- Bert -