2009/11/3 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Nov 3, 2009 at 1:51 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> 2009/11/3 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> >
>> > On Tue, Nov 3, 2009 at 1:06 PM, Nicolas Cellier
>> > <nicolas.cellier.aka.nice at gmail.com> wrote:
>> >>
>> >> 2009/11/3 Andreas Raab <andreas.raab at gmx.de>:
>> >> > Nicolas Cellier wrote:
>> >> >>
>> >> >> While at isSelfEvaluating, I wonder why we do not abuse {..}
>> >> >> notation
>> >> >> a bit more.
>> >> >> Instead of printing 'aSet( 0 at 0 1 at 2 )'
>> >> >> we could just make it evaluate proof '{0 at 0. 1 at 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 at 0. 1 at 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 at 0. 1 at 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 :)

Choice of << was in the same vein as C++ stream.
t's a kind of left arrow indicating streaming direction (fill my Set with...).
And <- is not a valid binary selector according to st80 syntax (unless
http://bugs.squeak.org/view.php?id=3616)

I agree on your first argument, binary selectors are hard to sell for
this very reason:
they are cryptic when keywords are expressive...
and we have already two #newFrom: #withAll: for that purpose...
... and also {} asSet, or {} as: Set. Probably too many already !

Having a single selector with totally different meanings is also not
the best idea.
It makes following senders chain a bit difficult.
Though (Set >> Set selectors anyOne) has nothing to do with a shift
and the context greatly helps.
That's why I dared proposing <<, but without much conviction, see the :)

Nicolas