First post here ... few days on Squeak ... some questions ....
Fabio Filasieno
fabio.filasieno at gmail.com
Sat Aug 25 14:09:14 UTC 2007
On Aug 25, 2007, at 10:43 AM, Matthias Berth wrote:
> Hi Fabio,
>
>
> welcome to the list!
Thanks :-). Love to be here.
> (((obj collect: [ :x | …])
> filter: [:x | …] )
> select: [:x | …])
>
> And with a pipe operator you would save a few parntheses here?
>
Yes but there is a problem with that.
to quote you:
"
(((point x:10) y:20) z:10)
And with a cascade operator you would save a few parntheses here?
"
I'm not on the `pipe vs parenthesis problem`, but `pipe vs cascade`.
> With unary message sends, the syntax gives you a kind of piping for
> free, just chain the messages:
>
> 'abc' reverse first isVowel
>
Ahaaaaa.... :-D ... got you ... so you DO like functional
transformations...
Then why not ...
'abc' reverse first isVowel asChars
| filter: [ :char | char isCaps]
| fold: [: xxx | ... ] with: 0 | toList
| collect: [:number | number + 1]
(messages are invented)
>
> Smalltalk syntax was deliberately designed to be simple, based on a
> few mechanisms. By the way, your pipe idea is reflected in some
> methods in the collection hierarchy:
>
> Collection>>select:thenDo:
> Collection>>select:thenCollect:
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.
I't the hardcoded sequence that sucks.
The pipe is what made Unix powerful ... imagine a Unix system where
you need
to hardcode compositions of processes.
example:
Do your prefer to have ...
ls
grep
lsThenGrep
or
lr
grep
ls ... | grep ...
??
I want flexible compositions !
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.
(((point x:10) y:10) z:10) ... see it's redundant (it's might be in
95% of cases, I don't have stats).
Can anyone do a stat on Smalltalk messages
to see how many times the cascade operator is used and the previous
message
returns self ? If this number is very high(say 90-95%) then this
would prove that the cascade operator
is useless, as parenthesis could be used;
then we would need a way to reduce parenthesis and an interesting
solution would be the Pipe operator.
we could get cascading
point x:10 | y:10 | z:10...
and get for free pipes & filters
x select: [:item | ... ]
| collect: [:item | ...]
| doThis doThat
| fold: [:item | ...] with:0
| mailItto: 'xxxx'
| log: [ :result | .... ]
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.
No we need a better way reduce parenthesis in as many cases as
possible. The pipe happens to work quite well as I can both do the
initialization of objects AND it supports the flexible pipe & filters
style.
proposal ...
make the ";" cascade operator send the message not the the previous
receiver but to the object returned by the previous message send.
Fabio
More information about the Squeak-dev
mailing list
|