Two questions about Smalltalk language design
Locked
 
|
Hello Smalltalkers,
I was interacting the other day with an user in a Scala mailing list, and he had some questions about Smalltalk. From his FP (functional programming) point of view there were some things that looked strange. I tried to reply to the best of my ability, but still I don't really know the background for these design decisions. So I come to you, real experts, hoping for some answers. The questions were: 1) Why do ST methods return "self" if nothing is explicitly returned? (he would have expected something like "Unit" in Scala, or "Void" - which I know makes little sense in a world like ST's, so I didn't include this in the Stackoverflow question) http://stackoverflow.com/questions/14047887/why-do-methods-return-self-by-default-in-smalltalk 2) In Collections, why does "add:" return the object being added, and not "self"? http://stackoverflow.com/questions/14047940/why-does-add-return-the-object-added-in-smalltalk-collections ---- The original interaction in the Scala mailing list (nice language, by the way) was here: https://groups.google.com/d/topic/scala-user/gPEJNAEZO-8/discussion Thanks a lot in advance! Sebastian _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
There are more knowledgeable people around here, but here is my take:
On Wed, Dec 26, 2012 at 4:32 PM, Sebastian Nozzi <[hidden email]> wrote: > Hello Smalltalkers, > > I was interacting the other day with an user in a Scala mailing list, > and he had some questions about Smalltalk. From his FP (functional > programming) point of view there were some things that looked strange. > I tried to reply to the best of my ability, but still I don't really > know the background for these design decisions. So I come to you, real > experts, hoping for some answers. > > The questions were: > > 1) Why do ST methods return "self" if nothing is explicitly returned? > (he would have expected something like "Unit" in Scala, or "Void" - > which I know makes little sense in a world like ST's, so I didn't > include this in the Stackoverflow question) > > http://stackoverflow.com/questions/14047887/why-do-methods-return-self-by-default-in-smalltalk >From the language design POV, it's certainly better than simply returning the value from the last expression in the method. If it returns the last value in the expression: the following method would return the result from #doSomething; but to know what kind of object would be returned from it, you need to recursively look into many methods. method1: var1 var1 doSomething. Why not return something along the line of nil is.... It certainly is more useful to be able to chain messages for simple setters. > 2) In Collections, why does "add:" return the object being added, and > not "self"? > > http://stackoverflow.com/questions/14047940/why-does-add-return-the-object-added-in-smalltalk-collections Smalltalk-72's "vector" had that semantics more or less, when assigning a new value to a slot. Check out "to vector" in http://ftp.squeak.org/goodies/Smalltalk-72/ALLDEFS I can see some reason for that semantics: One perhaps was that because assignment was just a message send to a quoted variable, and you can define its behavior based on the receiver. When the receiver is a quoted vector, your assignment can update a slot of it. In many languages (not in Scheme however), the value of the assignment is the value to be assigned so you can say: x := y := 0. So, it is convenient to make the value of such message to be the value to be assigned. Another is that it certainly is convenient to get back the removed element when you are removing an element from a collection. Making add: do the same makes it more symmetric. -- -- Yoshiki _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
In reply to this post by senTalker
1. If a message does not return self, then you wouldn't be able to chain messages
together or to cascade messages. for example: |s| s := Sphere new. s rotateLeft; rotateRight; spin 60. would have to be: s rotateLeft. s rotateRight. s spin 60. 2. If you add an object to a collection, most times you are still concerned with the object, not the collection. I know what you mean that a lot of times you build an object and when it is complete you store it in a collection and move onto something else. But there is no reason adding has to be the final step. For example, I pour coffee into my cup, (Cup new) add: coffee, then I stir the coffee, (coffee stir) . > 1) Why do ST methods return "self" if nothing is explicitly returned? > (he would have expected something like "Unit" in Scala, or "Void" - > > > 2) In Collections, why does "add:" return the object being added, and > not "self"? _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
On Thu, Dec 27, 2012 at 1:04 PM, Joseph J Alotta <[hidden email]> wrote: 1. If a message does not return self, then you wouldn't be able to chain messages Cascading using semicolons would still work if methods didn't answer self, but would be less useful in some circumstances. The cascade rule is that subsequent messages get sent to the same receiver as the most recent one, so in
s rotateLeft; rotateRight; spin: 60 all of the messages get sent to s - no matter what they return.
But here's where it's useful for simple modifier messages like these to answer self: say we had s := Sphere new rotateLeft;
rotateRight; spin: 60. Here the last three messages get sent to the result of (Sphere new). The result of the the entire cascade is the result of the last message sent, spin:. Since spin: answers self, we can do the Sphere creation and setup all in one cascade. Otherwise we'd have to split it:
"If spin: didn't answer self" s := Sphere new. s rotateLeft; rotateRight; spin: 60.
Ben _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
In reply to this post by senTalker
On 2012-12-27, at 01:32, Sebastian Nozzi <[hidden email]> wrote:
> Why do ST methods return "self" if nothing is explicitly returned? One very simple reason has not been stated yet: In the Virtual Machine, returning self is simpler and more efficient than returning any other object. Smalltalk byte codes implement a stack machine. That means arguments are passed by pushing them onto a stack, rather than putting them into registers. In addition to the arguments as listed in the method signature, a hidden argument is always passed, which is the receiver of the message. So even for unary methods (those without arguments) the receiver is pushed onto the stack, then the method is executed, and the receiver value on the stack is how the method knows "self". By returning "self" if no explicit return statement is given, the VM can just leave the "self" oop on the stack, which saves at least one memory store operation. So from an efficiency and simplicity standpoint, returning "self" is the most elegant thing to do. - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
In reply to this post by Benjamin Schroeder-2
On Thu, 27 Dec 2012, Benjamin Schroeder wrote:
> > > On Thu, Dec 27, 2012 at 1:04 PM, Joseph J Alotta <[hidden email]> wrote: > 1. If a message does not return self, then you wouldn't be able to chain messages > together or to cascade messages. > > for example: > > |s| > > s := Sphere new. > > s rotateLeft; rotateRight; spin 60. > > would have to be: > > s rotateLeft. > s rotateRight. > s spin 60. > > > Cascading using semicolons would still work if methods didn't answer self, but would be less useful in some circumstances. > > The cascade rule is that subsequent messages get sent to the same receiver as the most recent one, so in > > s > rotateLeft; > rotateRight; > spin: 60 > > all of the messages get sent to s - no matter what they return. > > But here's where it's useful for simple modifier messages like these to answer self: say we had > > s := Sphere new > rotateLeft; > rotateRight; > spin: 60. > > Here the last three messages get sent to the result of (Sphere new). The result of the the entire cascade is the result of the last message sent, spin:. Since spin: answers self, we can do the Sphere creation > and setup all in one cascade. Otherwise we'd have to split it: > > "If spin: didn't answer self" > s := Sphere new. > s > rotateLeft; > rotateRight; > spin: 60. the return value of #spin: : 1: (s := Sphere new) rotateLeft; rotateRight; spin: 60 2: s := Sphere new rotateLeft; rotateRight; spin: 60; yourself Levente > > Ben > > > _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
In reply to this post by Bert Freudenberg
On Sun, Dec 30, 2012 at 7:40 AM, Bert Freudenberg <[hidden email]> wrote:
> On 2012-12-27, at 01:32, Sebastian Nozzi <[hidden email]> wrote: > >> Why do ST methods return "self" if nothing is explicitly returned? > > > One very simple reason has not been stated yet: In the Virtual Machine, returning self is simpler and more efficient than returning any other object. > > Smalltalk byte codes implement a stack machine. That means arguments are passed by pushing them onto a stack, rather than putting them into registers. In addition to the arguments as listed in the method signature, a hidden argument is always passed, which is the receiver of the message. So even for unary methods (those without arguments) the receiver is pushed onto the stack, then the method is executed, and the receiver value on the stack is how the method knows "self". By returning "self" if no explicit return statement is given, the VM can just leave the "self" oop on the stack, which saves at least one memory store operation. So from an efficiency and simplicity standpoint, returning "self" is the most elegant thing to do. I thought of it (when I wrote the reply) but isn't this really the argument for returning self instead of nil for example? Any message send pops all arguments including the receiver and pushes the return value so "self" is not on the stack. Typical byte code sequence for a method that returns self is popping the last result and ends the sequence with "returnSelf"; so it should be equally efficient if such a method endsWIth "returnNil", if such bytecode exists? -- -- Yoshiki _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Two questions about Smalltalk language design
|
|
In reply to this post by Bert Freudenberg
Top post: I never once thought about that, and it makes me smile.
On Dec 30, 2012, at 7:40 AM, Bert Freudenberg <[hidden email]> wrote: > On 2012-12-27, at 01:32, Sebastian Nozzi <[hidden email]> wrote: > >> Why do ST methods return "self" if nothing is explicitly returned? > > > One very simple reason has not been stated yet: In the Virtual Machine, returning self is simpler and more efficient than returning any other object. > > Smalltalk byte codes implement a stack machine. That means arguments are passed by pushing them onto a stack, rather than putting them into registers. In addition to the arguments as listed in the method signature, a hidden argument is always passed, which is the receiver of the message. So even for unary methods (those without arguments) the receiver is pushed onto the stack, then the method is executed, and the receiver value on the stack is how the method knows "self". By returning "self" if no explicit return statement is given, the VM can just leave the "self" oop on the stack, which saves at least one memory store operation. So from an efficiency and simplicity standpoint, returning "self" is the most elegant thing to do. > > - Bert - > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
I may be a total beginner, but if you think of it as objects instead of code: One object sends a message (the sender), the receiving object (the receiver) dies something if it understands the message, and then gives the sender a reply. If the message where a void (no reply), the sender would get stuck waiting for confirmation, or something along those lines. And nil is just a name for "nothing", so returning nil would be the same as nothing. That's how I see it at least. And if you think about the fact that Smalltalk was designed to teach children how to code, it makes at least some sense. On Dec 30, 2012 9:04 PM, "Casey Ransberger" <[hidden email]> wrote:
Top post: I never once thought about that, and it makes me smile. _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |