First post here ... few days on Squeak ... some questions ....

Jason Johnson jason.johnson.081 at gmail.com
Sat Aug 25 18:11:10 UTC 2007


On 8/25/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
>

Hi, welcome to the list and Smalltalk. :)

> I'm not on the `pipe vs parenthesis problem`, but `pipe vs cascade`.

There is no "pipe vs cascade" problem.  In Smalltalk the language is
based sending messages to objects.  If you want to send a message to
the result of the last send then you can just do it.  If you wish
instead to send more messages to a previous object you can use the
cascade operator.

So if you want "pipe" behavior you have it already.  The only time
parenthesis are needed is when there is ambiguity about evaluation
order.

Haskell uses the $ operator to reduce the need to have parenthesis in
a manner you're suggesting.

> Ahaaaaa.... :-D ... got you ... so you DO like functional
> transformations...

Of course, Smalltalk is full of them.

> This is very very ugly ... It's like hardcoding.
> Dump all those do:thenDo:thenDo. It's the ugliest part of smalltalk.
> I saw posts on the internet with the same argument and I don't buy it.

These are just convenience methods.

> Just dump the cascade for the pipe ... and you have just added to
> smalltalk
> part of the power of the unix pipe&filter.
>
> It's better because the cascade is redundant.

In what way?

>
> (((point x:10) y:10) z:10) ... see it's redundant (it's might be in
> 95% of cases, I don't have stats).

Are you sure you know what the cascade operator is doing?  It can't be
redundant because there is no other way to do what it's doing without
using temp variables.

E.g. if "point x: 10" returns 10 then you can't go:

(point x: 10) y: 10

because the "y: 10" goes to the other 10.  You must either use
different statements as in:

point x: 10.
point y: 10.
"..."

Or you can use the cascade operator as in:

point x: 10; y: 10.

So where is the redundancy?

> Cascading is redundant if the previous message returns self as
> parenthesis could be used.
> In MY case, ALL cascade operations are redundant as I use them for
> setting properties during object initialization, therefore returning
> self.
> Since cascading is redundant (in my case), therefore we can remove
> the cascade operator.

Lol.  *You* don't need cascading so we should break with the Smalltalk
80 spec, break backward compatibility with.... pretty much all
Smalltalk code written until now, and have to type out verbose repeat
statements over and over since we have no cascade operator anymore?
Does that really seem logical/realistic to you?

My suggestion would be to learn the language before redesigning it. ;)



More information about the Squeak-dev mailing list