On Aug 25, 2007, at 8:11 PM, Jason Johnson wrote:

> On 8/25/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
>>
>
> Hi, welcome to the list and Smalltalk. :)
>

Thank's Jason ... really happy to be here ....

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

No you don't ...

This is ugly ...
((( obj collect: [ :x | ....] ) filter: [:x | …] ) select: [:x | …])

This is beautiful ...
obj | collect: [ :x | ....]
        | filter: [:x | …]
        | select: [:x | …]

> Haskell uses the $ operator to reduce the need to have parenthesis in
> a manner you're suggesting.
>
Haskell's $ is ugly again ...
because you would need to write backwards .... there are better ways  
(Arrows)

Why on hell I have to read from right to left ....

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

Are you suggesting That I need to write convenience methods at every  
single bind I do ?
I know you could do that ... but it's ugly ...

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

There is quite some redundancy - as I stated before - when the method  
returns self.
In MY case I use the cascade on setter methods.

And for that you dump the ability to compose processes ?? You dump  
the power of UNIX ?

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

Nope ... but I might hack the compiler .... and see if someone likes  
the new image, since it's smalltalk,
and we can change anything ....

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



I'm not redesigning it, I'm currently writing an interpreter for a  
programming language and it happens that I selected Squeak for that ...
I'll probably start hacking Smalltalk a little anyway ... and yes I  
like breaking Specs ... you never now. Sometimes something nice comes  
up ... :-)

Fabio


P.S. The `uglys` here are obviously my personal taste.


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