About {} and its limits
Alexandre Bergel
bergel at iam.unibe.ch
Sat Feb 12 18:10:43 UTC 2005
I just had a look at the Array>>brace* methods. I do not understand why there are in the image since with:with:... exist.
Alexandre
On Tue, Feb 08, 2005 at 05:26:59PM +0100, Bert Freudenberg wrote:
>
> 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 -
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
More information about the Squeak-dev
mailing list
|