>
>
> On Tue, Nov 3, 2009 at 1:51 PM, Nicolas Cellier
> <[hidden email]> wrote:
>>
>> 2009/11/3 Eliot Miranda <[hidden email]>:
>> >
>> >
>> > On Tue, Nov 3, 2009 at 1:06 PM, Nicolas Cellier
>> > <[hidden email]> wrote:
>> >>
>> >> 2009/11/3 Andreas Raab <[hidden email]>:
>> >> > Nicolas Cellier wrote:
>> >> >>
>> >> >> While at isSelfEvaluating, I wonder why we do not abuse {..}
>> >> >> notation
>> >> >> a bit more.
>> >> >> Instead of printing 'aSet( 0@0 1@2 )'
>> >> >> we could just make it evaluate proof '{0@0. 1@2} asSet'
>> >> >>
>> >> >> Of course, with limited stream, we take the risk of loosing trailing
>> >> >> '
>> >> >> asSet' information.
>> >> >> So we can also print using a less nice but still evaluating 'Set
>> >> >> newFrom: {0@0. 1@2}'.
>> >> >>
>> >> >> As a bonus, generalizing this behaviour might also eliminate a few
>> >> >> bytecodes and methods from the Kernel.
>> >> >>
>> >> >> Same for storeOn:
>> >> >>
>> >> >> What do you think ?
>> >> >
>> >> > -1. The goal of printing isn't to make parsing easier. In fact I find
>> >> > this
>> >> > to be the least useful application of {} - the advantage of the
>> >> > syntax
>> >> > form
>> >> > is that it is immediately recognized and consequently requires less
>> >> > effort
>> >> > than having "an Array(". That you can also evaluate it in some
>> >> > situations is
>> >> > a useful side effect but no more.
>> >> >
>> >> > Cheers,
>> >> >  - Andreas
>> >> >
>> >>
>> >> OK, I see ' newFrom: ' can be considered as noise, so we can't have
>> >> our cake and eat it too ?
>> >> I find the fact that simple objects print as a simple code snippet
>> >> such a nice feature though...
>> >> Set << {0@0. 1@2} would be short, but I guess introducing a new binary
>> >> selector will be hard to sell :)
>> >
>> > yuck.  asSet is readable and in the Smalltalk tradition.  << sMLells ;)
>>
>> Like http://en.wikipedia.org/wiki/ML_%28programming_language%29 ?
>
> 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 :)
> 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 :)