About {} and its limits
Bert Freudenberg
bert at impara.de
Tue Feb 8 16:26:59 UTC 2005
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 -
More information about the Squeak-dev
mailing list
|