A non-text attachment was scrubbed...
Name: Array-printOn.st
Type: application/text
Size: 326 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050208/9a11ec87/Array-printOn.bin
-------------- next part --------------


Here is the discussion that led to this choice

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.


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

But you did not reply to my point.

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

But for that {} should be more first class. With the current solution 
it stops in the middle
at the parser level.

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

serialization is different than self representation.
you could have a compressed serialized form, or a xml one or whatever.

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

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

> However, what would be even better is if you would get a reference to 
> the *same* object that was printed.

Exactly! So the previous wishe is a first step in that direction. In 
Scheme the self-evaluating/printing  provides a bit this.

> We just do not have the right tools for that. An inspector is 
> unwieldy. MorphicWrappers probably come closest.

Exact. May be self was the 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.

yes this would reinforce the concretness of objects as dave Ungar and 
Smith wrote in their paper.

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

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.

Thanks for this discussion since I learned something on my own 
knowledge.

Stef