pipe operator

I like the idea of a pipe operator just like I like the ';' operator.
They are both (and independently) useful.
However, I object to using the '|' symbol for this. 
(How about using  '::' or  ':-:'  instead?)

I think the '|' operator should be used to plug output streams into input streams
just as it is used between processes in linux shells.

To use such an operator we first we need objects
that (in the most general case)
read data from an input stream, process the stream,
and then output the result to an output stream. 
Let  b1, b2, b3  be three such objects,  'in'  be an input stream,
and 'out' be an output stream.
Then we could write:

b1 < in; > out.  

to have  b1 read its input from 'in' and put its result into  'out'.
Note that 'b1 < in'  cannot generate any output since b1 does not yet know
where to send it.  After the  '; > out.'  b1 can process its input and put its
output into 'out'.

Now we can write:

b1 < in; | b2 | b3 > out.

which has
b1 read its input from 'in', process its input, and send its output to  b2,
b2 process its input (the output of b1) and send its output to b3,  and
b3 process its input (the output of b2) and put its output into 'out'.

To have this work well there would need to be objects called pipes
that do most of the data moving between  b1, b2, b3.
Thus the method   '|'  would look something like:

| b
pipe := Pipe output: b.
self > pipe.

Perhaps things would not work exactly as I have described
but you get the idea.
Suggestions as to better syntax welcome.

Notes:
1)  No change to Squeak or any other version of Smalltalk is needed.
     (unless we want cleaner syntax);
     we only need to implement this feature. 
     Anybody want to write a pipes package?
     Given how useful pipes are in linux shells,
     it surprises me that a pipes package hasn't been written before.
2)  Some collection classes could be made to act like streams with regard to pipes;
     we just need to implement the necessary methods.
3)  Class Pipe could have subclasses each of which would have different internal
      implementations for efficiency reasons.

Ralph Boland