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