Hello,
Fair enough. I'll be more careful. But, if we where talking face to face you would see a smile on my face not an ... aggressive face.
Well, that's a fair point. The actual words only count about 10% of actual communication, so it can be very hard to judge someones intentions.
Of course, there is no empirical research result that supports a claim like this (10% or, "7%-38%-55%"). I don't think reasonably carefully written text (even emails) is less effective than verbal communication. If one feels that he has to use many exclamation marks in a row or many capitalized words when he is supposed to convince people logically, it is a "smell" of lack of deep logic.
... And going back to the main topic...
I don't see real benefit to change the language just to achieve a very tiny, tiny subjective benefit at some corner cases. As many have pointed out, the unary messages or binary messages are already "piped" (strange word, as they are just ordinally chained expressions after all). So, insisting that Smalltalk-80 lacks the concept is not simply true. And, making an object that holds the current value (or a context) and sending cascaded messages to it has the same effect, as Bert and others have shown. collect:thenSelect: is a weirdo, but there aren't too many of such guys.
Many proposed syntax for it in this thread are tiny syntax sugar, and comes with a lot of unnecessary surprises. (I like the clever tricks and aesthetic sense people have shown, though.)
BTW, to the eyes of a real functional programmer, the message patterns connected with '|' looks like a pattern matching expression. This will be another reason to say it is an unnecessary surprise.
If we think about the magnitude of changes from Smalltalk-72 to Smalltalk-76 to Smalltalk-80, I hope the change to the language has that kind of magnitude. Traits in Squeak really didn't turn out be as successful as it should have been, but that kind of change, for example. Pipe sounds to me like connecting multiple processes. It would be a nice change to a language.
In regards to cascading and semi-colon and these issues, I think first we can get rid of semi-colon altogether. Today, a typical use of cascading is like this:
self layoutPolicy: TableLayout new; listDirection: #leftToRight; wrapCentering: #topLeft; hResizing: #spaceFill; vResizing: #spaceFill
if these keywords messages were truly unordered and optional, we could write it in this way:
self layoutPolicy: TableLayout new listDirection: #leftToRight wrapCentering: #topLeft hResizing: #spaceFill vResizing: #spaceFill
and could make any order of these keywords to mean the same thing. Then, the need for semi-colon can be alleviated. Perhaps then, using it for omitting a pair of parenthesis might be a reasonable thing to do. Or not. For Transcript or the renderer in Seaside, these should be ordered...
-- Yoshiki