<br><br><div class="gmail_quote">On Tue, Nov 3, 2009 at 1:51 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/11/3 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div class="h5">><br>
><br>
> On Tue, Nov 3, 2009 at 1:06 PM, Nicolas Cellier<br>
> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
>><br>
>> 2009/11/3 Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>>:<br>
>> > Nicolas Cellier wrote:<br>
>> >><br>
>> >> While at isSelfEvaluating, I wonder why we do not abuse {..} notation<br>
>> >> a bit more.<br>
>> >> Instead of printing 'aSet( 0@0 1@2 )'<br>
>> >> we could just make it evaluate proof '{0@0. 1@2} asSet'<br>
>> >><br>
>> >> Of course, with limited stream, we take the risk of loosing trailing '<br>
>> >> asSet' information.<br>
>> >> So we can also print using a less nice but still evaluating 'Set<br>
>> >> newFrom: {0@0. 1@2}'.<br>
>> >><br>
>> >> As a bonus, generalizing this behaviour might also eliminate a few<br>
>> >> bytecodes and methods from the Kernel.<br>
>> >><br>
>> >> Same for storeOn:<br>
>> >><br>
>> >> What do you think ?<br>
>> ><br>
>> > -1. The goal of printing isn't to make parsing easier. In fact I find<br>
>> > this<br>
>> > to be the least useful application of {} - the advantage of the syntax<br>
>> > form<br>
>> > is that it is immediately recognized and consequently requires less<br>
>> > effort<br>
>> > than having "an Array(". That you can also evaluate it in some<br>
>> > situations is<br>
>> > a useful side effect but no more.<br>
>> ><br>
>> > Cheers,<br>
>> > - Andreas<br>
>> ><br>
>><br>
>> OK, I see ' newFrom: ' can be considered as noise, so we can't have<br>
>> our cake and eat it too ?<br>
>> I find the fact that simple objects print as a simple code snippet<br>
>> such a nice feature though...<br>
>> Set << {0@0. 1@2} would be short, but I guess introducing a new binary<br>
>> selector will be hard to sell :)<br>
><br>
> yuck. asSet is readable and in the Smalltalk tradition. << sMLells ;)<br>
<br>
</div></div>Like <a href="http://en.wikipedia.org/wiki/ML_%28programming_language%29" target="_blank">http://en.wikipedia.org/wiki/ML_%28programming_language%29</a> ?<br></blockquote><div><br></div><div>ML. I remember seeing an ML program at Queen Mary that had about 25 user-defined operators in its precedence table. One has to be a sadist or a monk to define one's own operators with one's own precedence. A sadist if one expects anyone else to read the program, and a monk otherwise :)</div>
<div><br></div><div>I can sort of live with << and >> for shift because they're used in more than just C, but overloading it for collection creation is IMO a step too far :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Oh, didn't know about this one<br>
<a href="http://en.wikipedia.org/wiki/Miranda_%28programming_language%29" target="_blank">http://en.wikipedia.org/wiki/Miranda_%28programming_language%29</a><br>
<br>
Using asSet is taking the risk of loosing class information because of<br>
<br>
printStringLimitedTo: limit<br>
"Answer a String whose characters are a description of the receiver.<br>
If you want to print without a character limit, use fullPrintString."<br>
| limitedString |<br>
limitedString := String streamContents: [:s | self printOn: s]<br>
limitedTo: limit.<br>
limitedString size < limit ifTrue: [^ limitedString].<br>
^ limitedString , '...etc...'<br>
<br>
<br>
>><br>
>> Nicolas<br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
</blockquote></div><br>