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(a)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.