Just a kibitz from the peanut gallery....

It's not a question of functionality, but of simple readability and 
writeability. This idea has come up a number of times in the past, 
and it is a very reasonable one. In fact, there are a number of other 
perfectly reasonable additions that would be nice to have in 
Smalltalk. The basic idea of having a flat precedence for binary 
operators came from the same practice in APL -- if you have a zillion 
of them, then just using grouping instead of precedence can be a 
reasonable solution.

But, for example, the "." could be considered to be a kind of 
operator (that is like a procedural "AND") that tests to see if the 
previous expression SUCCEEDed before moving to the next expression. 
We could think of it as being defined in Class Object. If we think of 
"precedence" then we want everything else in expressions to be more 
closely bound.

This opens up the possibility of having something like "|" (apologies 
for using this for a different purpose) to deal with the "OR" case. 
So if an expression FAILs, then the OR path will be taken. It is easy 
to see why we should use precedence ideas here to avoid parentheses.

Note that the overloading of these operators with a little more 
processing could lead both to a "Prolog" way of thinking about things 
on the one hand, and a way to think of parsing and searching, on the 
other. Both of these would be great additions to the basic semantics 
of Smalltalk.

And so would pipes. They provide a syntactical way of writing very 
useful sequences of processing that is much nicer than functional 
application syntax (which gives a difficult to read "backwards 
view"), and Haskell did absolutely the right thing in making an 
operator for this.

Since Squeak is a completely open Smalltalk, and intended to be 
extended in major as well as minor ways, there is no reason 
whatsoever to prevent these ideas and more to be added (and I wish 
that people would take it upon themselves to extend the language).

Cheers,

Alan

At 11:40 AM 8/25/2007, Jason Johnson wrote:
>On 8/25/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
> >
> > check this out ...
> >
> > (((((((((((obj message1: param) message2:param) message1: param)
> > message2:param) message1: param) message2:param) message1: param)
> > message2:param) message1: param) message2:param) message1: param)
> > message2:param
>
>This is a bit contrived.  If you ever did find the need to do this it
>should look like:
>
>
>(((((((((((obj message1: param)
>   message2:param)
>     message1: param)
>       message2:param)
>         message1: param)
>           message2:param)
>             message1: param)
>               message2:param)
>                 message1: param)
>                   message2:param)
>                     message1: param)
>                       message2:param
>
>Code smell to be sure, but you pile what you don't like on one line
>and say you can't read it while formatting what you do like and saying
>"see!".
>
> > The pipe is needed to support a pipe&filter style of programming. That
> > perfectly works with Smalltalk syntax, and truly
> > opens up a better way of doing functional transformations.
>
>pipe&filter style of programming?  Most people call this "functional
>programming" and it doesn't require a pipe operator to work.  Such an
>operator can make certain code cleaner to be sure, but it doesn't
>"open up a better way of doing functional transforms" by any means.
>Just saves you one character per function call.
>
> >  >>>>>>>>> cascade is useless <<<<<<<<<<<<
> >
> > because it's redundant :
> >
> > Example :
> >
> > point x:10; y:10; z:10.
> >
> > Your could write in fact.
> > (((point x:10) y:10) z:10)
> > since x:10 returns self anyway, y:10 returns self anyway and z:10 returns
> > self anyway.
>
>In this case yes, one could use parenthesis, the cascade operator or a
>new statement delimiter (which you call "pipe").  But sometimes you
>wish to send a bunch of messages to an object that may not return
>self.
>
> > With the pipe I removed parenthesis from much wider selection of cases, I
> > enable a cleaner way of writing functional transformations, and therefore
> > it's a better design.
>
>You don't have a conflict between cascade and your "pipe" unless you
>want to use the ; symbol.  Cascade is a special message that causes
>the compiler to put in some op codes for duplicating the cascaded
>object on the stack.  What you want is just the current behavior
>without needing the parenthesis to disambiguate.  I don't think it
>would be too hard to add a new symbol that has the compiler treat it's
>left side the same as it would if the statement was in parenthesis.