Hi All,

Before we decide what to do,

Considering the usefulness and compatibility issues I'd vote against the
change.  

To answer questions of compatibility I'd vote for #asPipe.  I disagree that
#asPipe is a bad name, #asSequencer is not better.

The pipe operator ;; to me is still the best operator choice.  It has some
relation to the ; operator and would be easier to remember then other
proposed symbols.  I disagree that it would be easy to type wrong.  It seems
to stick out to me.  I disagree that it would be difficult to learn or teach
since it seems to be two sides of the same problem.  Also I disagree that
the two will get confused since determining which is which is easy enough to
do.  But if we can not agree to use ;; then I would again vote for using
#asPipe, which successfully answers all of these arguments.  

Again I would probably not use ;; at all.  I prefer parens or temps because
they make much more sense.  At least ;; seems tolerable and possibly
marginally useful.

So overall considering the usefulness I'd vote in the following order.

-1
asPipe
;;

So I vote no.  But if we must have the change and enough people agree then
I'd change my no vote to vote for #asPipe.  Again if enough people insist on
an operator then ;; gets my vote and I still vote against other suggested
symbols.

Happy Coding!!

Ron Teitelbaum  


> -----Original Message-----
> From: Bert Freudenberg
> 
> 
> On Sep 3, 2007, at 0:19 , Andreas Raab wrote:
> 
> > Blake wrote:
> >> Claims were made that pipes could reduce code size by a factor of
> >> 10 while increasing clarity. If true, it's certainly worthy. Even
> >> by 2 would be hard to argue with. One thing about traits is that
> >> you can see how the code is cleaner (and even then, there's still
> >> resistance).
> >
> > Do you have an actual example of how the code is cleaner or are you
> > simply repeating what other people tell you? I've been looking for
> > good examples for traits for a couple of years now but it seems
> > that when things go beyond the toy examples presented in the papers
> > traits create more complexity than they help to address.
> >
> >> It's reasonable to ask for some evidence.
> >
> > Indeed. Correcting mistakes is reasonable too, but both usually
> > don't happen.
> 
> 
> Supposedly the "pipe syntax" is for helping to deal with to many
> parens, right? So I tried this:
> 
> 	| n found |
> 	found := OrderedCollection new.
> 	'Decompiling all classes...'
> 		displayProgressAt: Sensor cursorPoint
> 		from: 0
> 		to: CompiledMethod instanceCount
> 		during: [:bar |
> 			n := 0.
> 			SystemNavigation default allBehaviorsDo: [:cls |
> 				cls selectorsDo: [:selector |
> 					(n := n + 1) \\ 100 = 0
> 						ifTrue: [bar value: n].
> 					((cls decompile: selector)
decompileString
> includesSubString:
> '(((')
> 						ifTrue: [Transcript cr;
show: '***' ,
> cls name , ' ' , selector.
> 							found add: cls name
, ' ' ,
> selector]]]].
> 	SystemNavigation default
> 		browseMessageList: found asSortedCollection
> 		name: 'Triple Parens' autoSelect: '((('
> 
> 
> In my 3.8-based image this matched 96 of 50000 methods. These are
> mostly bit arithmetic and conditionals, and a few occurrences of
> multiple select:/collect:/do:'s. But honestly, none of them, even the
> latter, would benefit (IMHO) from the pipe operator.
> 
> I have the impression that Smalltalk has hit a "sweet spot" - there
> may be a few additions (compile-time expressions anyone?) but
> basically it is very succinct in expressing what the underlying
> system does, namely, sending messages to objects. Other languages
> needed to add a lot more over the years as they started out with a
> rather limited model, but if you start with a general model like
> Smalltalk did (which in turn was the result of many experiments) it
> is not necessary to add that much. Or, if you do it, it wouldn't be
> Smalltalk anymore (and that's in fact what Alan's group now is
> working on, there is a whole lot of experimenting with syntax going
> on using Meta).
> 
> - Bert -
> 
>