About {} and its limits
stéphane ducasse
ducasse at iam.unibe.ch
Tue Feb 8 21:06:50 UTC 2005
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.
>> 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.
see above.
>
>> 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 {}.
I did that but this was not my point.
>> 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 it does not work for {} and he could there is nothing that cannot
make it work.
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 ...).
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.
> 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
-------------- next part --------------
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/2e58a632/Array-printOn.bin
More information about the Squeak-dev
mailing list
|