On 8/26/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
>
> Duplicate... don't know. I think one temporary variable per activation
> should be enough, because you can overwrite it.

lol. come on!  Personally I weigh making a variable at the same level
as making a new method.  Sometimes I would choose making the method
instead, and this often leads to nice refactorings.

And it's not just a temp variable we are talking about, it's more
statements as well.  And you still haven't given any reason we need to
drop the cascade operator.  If you want pipe then make pipe.  That has
no effect on cascade unless you want the ; character.

> I can see that.
> But ... for example.
>
> collection := OrderedCollection new.
> collection add:1.
>
> evaluates to one. Why ? Why not to collection ?

As pointed out in another email, because it provides more
value/options this way.

> If you need guarantees than a strongly typed language is better.
> Why not having guarantees on types etc ... ?
> A working test is enough of a guarantee.

Having guarantees is not about strongly/late bound typing.  Smalltalk
has guarantees, just in a different place then something like Haskell.

> But in a new Smalltalk ? would you keep it ? is there any reason
> we NEED the ";" operator ? or is just because it's now common use ...

Yes, for sure I would.  There is no other operator that does what it
does.  I might add a Haskell-style $ operator as well, but that's a
different question.

> and overall the "|" could do the same thing and that other cases could be
> covered with another desing
> that would be extremely clean anyway.

Oh great, so we can redesign half of Smalltalk just so you don't have
to type some parenthesis.  And the "clean" part is your opinion.  I
find the cascade very elegant and clean.

> Fair enough. I'll be more careful. But, if we where talking face to face you
> would see
> a smile on my face not an ... aggressive face.

Well, that's a fair point.  The actual words only count about 10% of
actual communication, so it can be very hard to judge someones
intentions.

> I tried to motivate quite a lot my opinion.
> I might say from my point of view it's pure opinion wether you NEED or not a
> "cascade" statement delimiter.
>
> I might even get convinced otherwise with some examples ... !!!

Here is the thing:  It does not *matter* if we need it or not.  You
are talking about two seperate issues:

1) We need what you call a "pipe" operator
2) You don't think we need cascade

Point 1 is an easy sell.  I don't see why you are strongly for point
2.  I like the cascade operator and I find it useful.  If you don't,
don't use it.  You can just make a new operator that does the "pipe".

And another advantage of this is, I think it would be pretty trivial
to make the compiler treat everything to the left of a $ (or whatever
you choose) as though it were in parenthesis.  At that point you would
also have the option of actually putting the parens in automatically
on fileout, so that you're 100% compatible with all other Smalltalks
as well.

> At least I have tried to expose an issue with concrete examples on why the
> pipe is so important. No examples have come to defend the cascade... of
> course in a context of a new Smalltalk.

But again, we have that right now.  This is exactly how Smalltalk
works today.  The only thing the "pipe" is doing is giving us another
way to disambiguate for the parser.

SomeObject beSpecial bePretty beFast doStuff

works in the "pipe" way.  You are changing:

(Someclass new name: 'Fred' age: 20) drawOn: someCanvas

into:

Someclass new name: 'Fred' age: 20 | drawOn: someCanvas

This is a little helpful, but not to the point of tossing out
something that can't be done otherwise.  Especially when the tools
help out with adding parenthesis (if you download the dev image you
can just select a statement and type ( and it puts the whole thing in
parens).

> This pipe thing is repeated in history too. Haskell's monads are not really
> a pipe thing, but the monadic bind (>>=) operator is really close to that.

I was talking about the do operator, which makes Haskell look more
left to right, though it's still right to left for every statement.