On Aug 25, 2007, at 9:05 PM, Alan Kay wrote:

> Just a kibitz from the peanut gallery....
>
> It's not a question of functionality, but of simple readability and  
> writeability. This idea has come up a number of times in the past,  
> and it is a very reasonable one. In fact, there are a number of  
> other perfectly reasonable additions that would be nice to have in  
> Smalltalk. The basic idea of having a flat precedence for binary  
> operators came from the same practice in APL -- if you have a  
> zillion of them, then just using grouping instead of precedence can  
> be a reasonable solution.
>
> But, for example, the "." could be considered to be a kind of  
> operator (that is like a procedural "AND") that tests to see if the  
> previous expression SUCCEEDed before moving to the next expression.  
> We could think of it as being defined in Class Object. If we think  
> of "precedence" then we want everything else in expressions to be  
> more closely bound.
>
> This opens up the possibility of having something like  
> "|" (apologies for using this for a different purpose) to deal with  
> the "OR" case. So if an expression FAILs, then the OR path will be  
> taken. It is easy to see why we should use precedence ideas here to  
> avoid parentheses.
>
> Note that the overloading of these operators with a little more  
> processing could lead both to a "Prolog" way of thinking about  
> things on the one hand, and a way to think of parsing and  
> searching, on the other. Both of these would be great additions to  
> the basic semantics of Smalltalk.
>
> And so would pipes. They provide a syntactical way of writing very  
> useful sequences of processing that is much nicer than functional  
> application syntax (which gives a difficult to read "backwards  
> view"), and Haskell did absolutely the right thing in making an  
> operator for this.
>
> Since Squeak is a completely open Smalltalk, and intended to be  
> extended in major as well as minor ways, there is no reason  
> whatsoever to prevent these ideas and more to be added (and I wish  
> that people would take it upon themselves to extend the language).
>
> Cheers,
>
> Alan
>



:-o

If you are the Alan Kay I think you are... I'd like to tell you that  
you have deeply influenced my life and and the one of my kids (when  
I'll have some).
Thank you very very much. You will never be forgotten.

Said that ... :o)

> Note that the overloading of these operators with a little more  
> processing could lead both to a "Prolog" way of thinking about  
> things on the one hand, and a way to think of parsing and  
> searching, on the other. Both of these would be great additions to  
> the basic semantics of Smalltalk.

You are probably thinking at the parser combinator libraries of  
Haskell ... I think there is a grey area on the "." and ";" in  
smalltalk.
The reason is that ... I can't write within the language a  
terminator !!! Yes I can write an operator ... but for a terminator ?  
I need to hack the compiler.
It's the only grey area in SmallTalk ... (in my humble opinion of  
course)... and it comes out when I wanted to use messaging as  
functional transformations.

a := b + c. ^ a

What is := ?
What is ^ ?
What is . ?
What is I want to add a "Lazy PIPE" to do some kind of parser ?
Again hack the compiler ?

#(:= ^ .) are NOT messages ! they are not Objects ! But wait ... in  
Smalltalk everything should be an object right ? well in my opinion  
we are just close to that, but very very very close to that.
This is the grey area of ST. Maybe I'm wrong it's just a few days on ST.

Overall I still think that cascade is a worse addition to the  
language compared to the pipe.

> And so would pipes. They provide a syntactical way of writing very  
> useful sequences of processing that is much nicer than functional  
> application syntax (which gives a difficult to read "backwards  
> view"), and Haskell did absolutely the right thing in making an  
> operator for this.

It might seem that what they did with Haskell's "$" it's cool (If you  
are referring to that), ....  but you still read BACKWARDS !!! It's  
not the right thing !!! They use operator associativity for that ...  
making it right associative ...

add x y = x + y
mul x y = x * y
main = do
    print (mul 2 $ add 1 $ add 1 1)

its's ...

1 add: 1 | add: 1 | mul: 2
-----------------------------> Smalltalk with pipe.

they do it still backwards : again the difficult to read "backwards  
view"
print (mul 2 $ add 1 $ add 1 1)
            <-------------------------------

(Please Haskell zealots ... I know you can do it in Haskell )


the pipe I have in mind for smalltalk is the right thing, because it  
makes messaging combinable. Instead of making  
OneBigComplexLargeMethod. I might just combine some of them. Welcome  
to UNIX ! Only you have not only text but objects ! When I show the  
problem a lot of guys say to me: "look helper methods!    
selectThen:collect:". Sorry helper method sucks. Suppose you have n  
different methods of arity s. are you going to write for me
s at the power of n (not sure about it .. my statistics is a bit  
rusty) helper methods to cover all cases. I'm sure you don't. You  
want PIPES. So you don't have to deal with helper methods.

The pipe I have in mind perfectly blends with "messaging" ... because  
it's just sending a message to the return value of the previous  
method. Not only.

Also check out what this guy did...  http://www.fscript.org/ 
documentation/OOPAL.pdf .
I think it's a matter of taste. And my taste says that (Array  
Programming + PIPE) gives an extremely powerful collection  
manipulation system, which I think is the second most important part  
of a programming system (the first being that it must be written in  
itself).
Check what that guy did. It truly frees up your mind from one-object- 
at-a-time style of thinking. They don't have the PIPE, because they  
copied from Smalltalk. So they have the same problem. in F-Script you  
can't combine messages just like Smalltalk. Too bad.

> Since Squeak is a completely open Smalltalk, and intended to be  
> extended in major as well as minor ways, there is no reason  
> whatsoever to prevent these ideas and more to be added (and I wish  
> that people would take it upon themselves to extend the language).

I'll see what I can do.


Fabio