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

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

I'm not this is how we used it when we do a eval-print loop.

> 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 why rectangle and point
and not Array since we used so often.

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

Yes exactly so this means that we will always have a broken model.

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

Not only we could have a method hasSelEvaluatingForm and do a query  
before printing.
So at least for some cases we would tend towards a good solution.
Because the objects you want to self-evaluate are often literals +  
point, rectangle and arrays.

of course for other objects we do not have a nice

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

No I did not but I would really be curious to see where the system is  
relying on this printed representation. But with squeak everything is  
possible such as halospec method in Preference.