Am 08.02.2005 um 22:06 schrieb stéphane ducasse:

> I tried my idea on roel and I'm getting much more precise now.
> Let 's try to see if I can express it:  When you introduce a new  
> syntactic form, it is important that it is complete: evaluating it and  
> the result representation it returns should coherent compared to the  
> result.
> Printing { a . b} should return {a value . b value} and not #(a parsed)
> => {10 at 10} => {10 at 10} and not #(10 @ 10)
>
> store on serialization is different that having a self-evaluating  
> representation.
> I think that scheme is a nice example of what can be achieved by  
> self-evaluating, but this is easier than with object since it mainly  
> manipulated s-expr but when you evaluate an s-expr you get a  
> *representation* of the s-expr value, which you can fed in the  
> evaluator again.  And this representation is representing correctly  
> the resulting s-exprI think that we can do the same with objects, the  
> representation we get should just be coherent with the returned value  
> and represents it correctly. In the current system the representation  
> returned
>
> So in fact the fin part of it is that Array is broken to this respect  
> and {} is much more right
> since printing a array does not produce a representation that  
> consistently corresponds to the original array.

I still think you're interpreting more into what printString should do  
than intended. Most objects' printed form does not recreate the object  
when evaluated. The default printing mechanism just uses an article and  
the class name ("an Object"). Literals are supposed to print in their  
literal form. And additionally a few classes do it this way, mostly  
rather basic ones like Point or Rectangle.

> But you did not reply to my point.

Maybe I didn't get your point ;-)

> It does not have to be. I do not have to think it as a shortcut. with  
> the right printing form and object behind I would just get right. And  
> as a programmer I would not have to think that I need to code
> a special printOn: method to get the same form.

Well, someone has to code that special printOn: method, otherwise  
you'll get the current #() form or the superclass implementation which  
would print 'an Array(a b c)'.

> Yes. because in the past this was not the case for a lot of literals  
> and this was fixed. This was breaking this beauty.

Really? Literals didn't print as themselves? Anyway, you *cannot* fix  
it in general for the {} construct because the elements of the array do  
not necessarily have a printed form that is executable. This is only  
guaranteed for literals.

> So now I'm wondering how we can fix {}.
> Does it make sense
> 	- to change the Array>>printOn:  method

As long as literal arrays still print in their literal form I'd say  
yes, why not.

> 	- introduce a new subclass of Array + printOn: method

Or the other way around, a class LiteralArray, like this :

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-June/ 
002140.html

> After all these discussions, I think that the solution is to fix
> Array>>printOn: aStream to print {}
> and to keep #() for precisely the static array containing only  
> literals, since we can always
> recreate an array from {} and not the inverse.
>
> <Array-printOn.st>

Did you try a recompile of the whole system after this change? I  
strongly suspect that printOn: is used in places that require the  
literal form.

Also, I think I prefer #(1 2 3) over {1 . 2 . 3} ;-)

- Bert -