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