On Aug 25, 2007, at 4:39 AM, Igor Stasenko wrote:

> let me elaborate:
>
> a message1 | message2
>
> is equal to:
>
> a message1 message2
>
> and:
>
> a message1: param | message2: param2
>
> is equeal to:
>
> (a message1: param) message2: param2
>
>
> and as you can see writing code with so-called 'pipes' makes code  
> much cleaner


Igor expressed what I'm after....


On Aug 25, 2007, at 4:43 AM, Blake wrote:
> But the parens in the ST in the second one are almost a graphic  
> representation of the object being created, to which the message2  
> is being passed.
>

Look down ... the graphic representation is a poor one because It's  
too costly: too may parenthesis.

On Aug 25, 2007, at 4:51 AM, Matthew Fulmer wrote:
> Those two examples are exactly the same length in characters, so
> I don't see what metric qualifies one as much cleaner than the
> other.


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

there is this thing > ((((((((((((

now look the cleaner
pipe ....
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

now some mix and match ...

obj | send
        | left: a right:b
        | send | send | send
        | left: a right:b
        | message

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.


On Aug 25, 2007, at 4:51 AM, Matthew Fulmer wrote:
> Parenthesis are not very common in squeak, and this would be
> less common as parenthesis. Parentheses are more general
> too; you could not do this with pipes:
>
> dict at: (self keyFor: anItem) put: 3
>
> I am really missing what the point of this is

It's less general but since functional transformations are a very  
powerful idiom (Haskells monads, Haskells Arrows,
the Unix pipe, ... just to name a few) a little help from the  
language would be nice.
It' not a parentesis vs pipe problem, it's a pipe vs cascade. Why ST  
has the cascade ? Can someone explain it me ... Why need a special  
operator for that ? I don't care about cascading... but maybe there  
is something I'm missing.

>  Parentheses are more general too

Use Lisp than. Everything is a pair... and you'll have as many  
general parenthesis you want :-p ....  just joking ... I see you  
point but ... my argument is not pipe vs parenthesis, but pipe vs  
cascade, because I want the the pipe&filter style of programming

I state that:

  >>>>>>>>> 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.

but thanks to the ";" (cascade) you can write ...
point x:10; y:10; z:10.

Then I say ... ok so the designer wants to remove those ugly  
parenthesis ...
why not do a better job by using a more general operator ??

I can do the cascade stuff ...

point x:10 | y:10 | z:10

and .. magic ...
I can do better functional transformations, pipe&filters style.

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

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.

Fabio's proposal:

make the ";" cascade operator send the message not the the previous  
receiver but to the object returned by the previous message send.



Fabio Filasieno




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070825/40cf503b/attachment.htm