First post here ... few days on Squeak ... some questions ....
Locked
12345
... 7
12345
... 7
 
|
On 25-Aug-07, at 12:32 PM, Igor Stasenko wrote: > We need only minor changes to parser to add this syntax sugar, and no > changes in complier because it don't breaks old syntax or message > passing semantics. Wrong. x = y | y > 3 You can't use #| because it is already defined for use as a binary symbol. Binary symbols have well defined semantics and syntax. (ab) using #| would by definition break old semantics and syntax rules. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Security announcement - as of next week, passwords will be entered in Morse code. |
|
|
In reply to this post by Igor Stasenko
Igor Stasenko schrieb:
> We need only minor changes to parser to add this syntax sugar, and no > changes in complier because it don't breaks old syntax or message > passing semantics. > That's not exactly true. #| is a perfectly valid binary selector, and is implemented in several classes (Boolean or and related operations). You might get away with ! which is a legal binary selector in current Smalltalk but is not used anywhere in a standard Squeak image. I'm still not convinced that object someMessage ! message1: arg1 ! message2 is that much better readable than ((object someMessage) message1: arg1) message2 especially since more than one or two levels of parentheses are often a sign of code smell. That does not mean that I'm absolutely against language evolution - but a new feature should carry its own weight. The {} collection constructor is Squeak is pretty usable, and I thought that the multi-assignment was also pretty neat even though it was rarely used and eventually got kicked out. Another thing is that code interchange between different Smalltalk implementations is something that should not be jeopardized lightly. When packages use implementation idiosyncrasies, they are less likely to be ported. Cheers, Hans-Martin |
|
|
In reply to this post by timrowledge
tim Rowledge schrieb:
> > x = y | y > 3 Better use parentheses here: x = y | (y > 3) With #> you will at least get an exception because Boolean does not understand #>, but when you use #= instead the code will work but produce unexpected results when x = y but y ~= 3. Cheers, Hans-Martin |
|
|
In reply to this post by Igor Stasenko
> As observation..
> > This discussion is a good example of purists who throwing away > any new ideas just because they 'don't follow standard' or > 'can be done with current syntax'. > > Honestly I see no harm in adding a pipe '|' symbol as a > special syntax symbol, like cascade ';' or period '.' > A pipe is like continuation which simply does: evaluate > expression to the left, then continue evaluation with > expression to the right, taking left result as receiver. > We need only minor changes to parser to add this syntax > sugar, and no changes in complier because it don't breaks old > syntax or message passing semantics. It's a good idea, the pipe, but not necessarily a well thought through implementation. As Tim and Has point out, | is already used in several places in the image and using it for special syntax for the pipe would cause problems with existing code. As Hans mentions, there's also the issue of portability to other dialects. Fabio's proposal to hijack ; for a pipe operator is obviously a non starter, he clearly doesn't understand how much Smalltalk code relies on ;. The way to get past the purists isn't by argument, it's by showing them an implementation that works, and addresses their concerns. A working implementation is the difference between some who's serious about an idea and someone who's just complaining. It's easy to point at the old timers and blame them for blocking progress, it's much harder to do something that would actually be considered progress. Squeak is the perfect experimental platform, so if someone hacked it up, and it worked well, there's a fairly decent chance people will look seriously at it. Even if they don't, it could always be maintained as a private extension to the language (I'm sure many exist). Ramon Leon http://onsmalltalk.com |
|
|
In reply to this post by Alan Kay
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 |
|
|
In reply to this post by Ramon Leon-5
Since the selector #'|' is already taken for other purposes, why not use
#'!' instead (exclamation point instead of the bar)? |
|
|
In reply to this post by Joshua Gargus-2
On Aug 25, 2007, at 7:05 PM, Joshua Gargus wrote:
a sequence of filter, map, fold, zip, ... it's extreamly common in any case you have to do quite some collection manipulation. I don't know about other people, but I'll tell where I use it... Selection, Projection, Cartesian Product, Union, Difference, Intersection are operators that I use a lot in any data selection/manipulation context. I use them as an "embedded SQL" on objective data. You have persistent data in a file. You load the object graph. You query, delete, add, select data according to what results you get from Selection, Projection, Cartesian Product, Union, Difference, Intersection. Making easy to combine operators is not hypothetical ... the domain is the most popular: data selection and manipulation. The first thing that comes to my mind is websites. Example: db getBlogposts | filter: [ :blogPost | blogPost data < (today - 7 days)] | filter: [ :blogPost | db coolPosts includes: item ) | collectMails | do: [ :mail | "Happy to announce ..."] This kind of coding is extremely common ... the whole Python language is built around maps, tuples, list ... an in Ocaml and Haskell too ... the list/map libraries with their zip, foldr, foldl, etx ... It's easy to think how you would use these kind functions with the PIPE. |
Re: First post here ... few days on Squeak ... some questions ....
|
|
In reply to this post by Jason Johnson-5
On Aug 25, 2007, at 8:11 PM, Jason Johnson wrote:
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'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 ....
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 ...
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 ?
and we can change anything ....
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. |
|
|
In reply to this post by Ramon Leon-5
The backtick ( ` ) might look nicely and is unused yet :)
2007/8/26, Alan Lovejoy <[hidden email]>: > Since the selector #'|' is already taken for other purposes, why not use > #'!' instead (exclamation point instead of the bar)? > > > |
|
|
In reply to this post by Ramon Leon-5
On Aug 25, 2007, at 11:30 PM, Ramon Leon wrote:
I was a bit provocative because, I don't like the cascade and wanted to show that you most of the time you could do with out it ... getting more out of smalltalk ...
As I said I'll see what I can do about that.
Please, this is really unfair. Nobody ever blamed anybody. We are just having a good chat. My point was : the cascade operator sucks the pipe rocks, and I've shown IMHO why it's better. And I love any critic I can get. Fabio Filasieno |
|
|
In reply to this post by Ramon Leon-5
if we don't want to use up another character, then we could use two
semi-colons. a x:1 ;; y: 2 |
|
|
In reply to this post by Hans-Martin Mosner
On 25-Aug-07, at 1:14 PM, Hans-Martin Mosner wrote: > tim Rowledge schrieb: >> >> x = y | y > 3 > Better use parentheses here: x = y | (y > 3) Yah, dumb typo. See how this daft 'pipe' idea mangled my thought processes? With a 'pipe' that would be equivalent to (x=y) y >3 which if #y were a suitable message (like #size, for example) would work. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Solid concrete from the eyebrows backwards. |
|
|
In reply to this post by Ramon Leon-5
On 26/08/07, Ramon Leon <[hidden email]> wrote:
> > As observation.. > > > > This discussion is a good example of purists who throwing away > > any new ideas just because they 'don't follow standard' or > > 'can be done with current syntax'. > > > > Honestly I see no harm in adding a pipe '|' symbol as a > > special syntax symbol, like cascade ';' or period '.' > > A pipe is like continuation which simply does: evaluate > > expression to the left, then continue evaluation with > > expression to the right, taking left result as receiver. > > We need only minor changes to parser to add this syntax > > sugar, and no changes in complier because it don't breaks old > > syntax or message passing semantics. > > It's a good idea, the pipe, but not necessarily a well thought through > implementation. As Tim and Has point out, | is already used in several > places in the image and using it for special syntax for the pipe would cause > problems with existing code. As Hans mentions, there's also the issue of > portability to other dialects. > Yes, i missed that its already used as selector (just little scared using | in expressions, because its already used to define temps in methods and blocks). But i was after idea, no matter what symbol could be used for it. > Fabio's proposal to hijack ; for a pipe operator is obviously a non starter, > he clearly doesn't understand how much Smalltalk code relies on ;. > Yes, i agree, cascade operator is not something which can be just dropped out. > The way to get past the purists isn't by argument, it's by showing them an > implementation that works, and addresses their concerns. A working > implementation is the difference between some who's serious about an idea > and someone who's just complaining. It's easy to point at the old timers > and blame them for blocking progress, it's much harder to do something that > would actually be considered progress. > I like an idea because for me its obvious, that pipe operator will improve the code readability, and also helps type less when coding. I start typing expression not from '(' , but from message send, so first i have to type: a someMessage: param1 then i see that i need to send second message to result, but since my first message uses keyword selector i can't just continue typing and must go back and place '(' before send , and then ')' after it. and only then i start typing next message. Also, sometimes , if expression became too long, its hard to find place where i must put open parenthesis, thats where 'pipe' can be really helpful. Maybe some people are soo intelligent, that they start typing expression from 2 or 3 opening parenthesis, because they already see how their expression will look like. Sorry then, I'm not so gifted to see full expression in mind, which can be about 10 lines of code. ;) Let me remind you , people, that one of the strongest sides of smalltalk, is easy to read and easy to express code. And smalltalk was always after that idea, from its very birth. I just want to point that denying an idea which makes it even more simpler is against spirit of smalltalk. So, who the purist? :) > Squeak is the perfect experimental platform, so if someone hacked it up, and > it worked well, there's a fairly decent chance people will look seriously at > it. Even if they don't, it could always be maintained as a private > extension to the language (I'm sure many exist). > And about working implementation, you are right. I can do this. But i doubt that someone who against idea from its roots will use it someday. See, if i don't like lemons, you can buy me million of them, but i'm still will not eat them :) > Ramon Leon > http://onsmalltalk.com > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Hans-Martin Mosner
On Sat, 25 Aug 2007 13:07:45 -0700, Hans-Martin Mosner <[hidden email]> wrote:
> Another thing is that code interchange between different Smalltalk > implementations is something that should not be jeopardized lightly. > When packages use implementation idiosyncrasies, they are less likely to > be ported. Which is at odds with Squeak as experimental platform. I'm not sold on pipes in particular and I'm very opposed to clutter in general, but if we can come up with features that significantly reduce code we should embrace them without too much concern for portability. I seem to recall Alan suggesting that the quantity of code in the Squeak base could be reduced by an order of magnitude (from 50K to 5K?). That's a goal well worth pursuing, and other Smalltalks would follow suit were Squeak to succeed. |
|
|
In reply to this post by Igor Stasenko
>
> Yes, i missed that its already used as selector (just little scared > using | in expressions, because its already used to define temps in > methods and blocks). But i was after idea, no matter what symbol could > be used for it. > > > #| is to me unreadeable... as #! what about something composed #=>. I think it reflects quite well what the "pipe" is doing... > I like an idea because for me its obvious, that pipe operator will > improve the code readability, and also helps type less when coding. > depends... not especially to me since we don't always easily see what the returned object... and as said previously I don't find | or ! "readable" > Also, sometimes , if expression became too long, its hard to find > place where i must put open parenthesis, thats where 'pipe' can be > really helpful. > first some says it's sign of code smell and second, code highlighting helps a bit in this area since it highlight the opening or closing parens. Also, don't forget indentation... > Maybe some people are soo intelligent, that they start typing > expression from 2 or 3 opening parenthesis, because they already see > how their expression will look like. Sorry then, I'm not so gifted to > see full expression in mind, which can be about 10 lines of code. ;) > 10 line is too much... ;) actually, I've always find the pipe cool especially in linux but I don't find it obvious to understand... This said, I wouldn't mind having it in my image. What about using #=>. Is it already used (not in my image)? possible ? Cédrick |
|
|
In reply to this post by Tapple Gao
Andrew Tween wrote:
> if we don't want to use up another character, then we could use two > semi-colons. > a x:1 ;; y: 2 Actually, whatever token is used, it should NOT be one that would be a legal message selector. It's new syntax, and messages and syntax should be distinct. Your suggestion qualifies in that respect. But would it be too similar to the single ";" character? --Alan |
|
|
In reply to this post by cbeler
2007/8/26, Cédrick Béler <[hidden email]>:
> > actually, I've always find the pipe cool especially in linux but I don't > find it obvious to understand... This said, I wouldn't mind having it in > my image. > > What about using #=>. Is it already used (not in my image)? possible ? > > Cédrick I think the subject should not be compared directly with unix pipes. Unix pipes represent a way to reuse fixed parts of functionality - compiled programs. These are black boxes. As a result application logic for a shell script goes directly to the script itself which is flat. Smalltalk is very different - you always can add behaviour you need to the other object and the application logic is distributed across the system. Long chains of unary selectors (analog for the discussed operator) are often considered as a code smell because this may put functionality to a wrong place. For instance, if one sees something like "self myOrganization hrDivision currentHRManager suggestApplicant" - he may consider to factor the code fragment to the hrDivision class. But there are cases when such chaining is obviously useful - I'm personally annoyed by the excessive parenthesises (or looking for shortcuts) while doing collection processing (that was one of the examples) and also when I have to combine boolean messages, for instance something like that: ((thingOne isSuch or: [thingTwo isThat]) and: [thing isNotEmpty]) or: [self whatever]) ifTrue: [self doSomething] (assuming evaluating operators don't work here). This example is not concrete of course but I recall when I was frustrated having to write similar code. cheers, Danil |
|
|
In reply to this post by cbeler
On Sun, 26 Aug 2007 00:19:42 -0700, Cédrick Béler <[hidden email]> wrote:
> What about using #=>. Is it already used (not in my image)? possible ? I liked the left-pointing arrow for assign...why not a right-pointing arrow for pipe? 'course, there is a ==> operator, and I think at some point we're getting into unwanted subtleties. What about an actual pipe? Or did the Squeak community come down against using special characters? |
|
|
Blake a écrit :
> On Sun, 26 Aug 2007 00:19:42 -0700, Cédrick Béler <[hidden email]> wrote: > >> What about using #=>. Is it already used (not in my image)? possible ? > > I liked the left-pointing arrow for assign...why not a right-pointing > arrow for pipe? ' it's used to build association... |
|
|
In reply to this post by Danil Osipchuk-2
On Aug 26, 2007, at 10:16 AM, danil osipchuk wrote:
That's not the point, but you are right, Unix and Smalltalk are different. In regard to the black boxes thing. self is the input of a process which is defined the class of self. The dispatch system when I do: obj doSomeStuff will send obj to a process called doSomeStuff. self is the input of process. ps -aux | grep 'fabio' | sort is like: Squeak ps: 'aux' | grep: 'fabio' | sort But this could be more object oriented in the sense that we are not passing text but objects. It could be better factored. What objects give you is .... polymorphism. This way you don't have to write This is Unix (or C style) style . MyData_doSomeStuff MyOtherData_doSomeStuff MySomeOtherData_doSomeStuff you need to have a unique identifier for the method. This is with objects doSomeStuff defined in MyData doSomeStuff defined in MyOtherData doSomeStuff defined in MySomeOtherData The difference is in text only vs objects, but at the end of the day you have a process (the method), you have an input(self), you have a return value(well... the ^value :o) ). I think there are a lot of analogies.
It's true but I like it that way when I'm prototyping !!! because I can quickly do stuff by reusing methods.
This is a good example. If and only if you have already there all the methods you suggested I would do that way the first time. Quick and easy. Than I would do some testing code. Than I would make it better (factoring) and faster (fixing the algorithm), making sure that I don't not break the tests.
This is my worst frustration too in SmallTalk. Fabio |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |