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-de...
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-a...
----
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
There are more knowledgeable people around here, but here is my take:
On Wed, Dec 26, 2012 at 4:32 PM, Sebastian Nozzi sebnozzi@gmail.com 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:
- 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-de...
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.
- In Collections, why does "add:" return the object being added, and
not "self"?
http://stackoverflow.com/questions/14047940/why-does-add-return-the-object-a...
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
On 2012-12-27, at 01:32, Sebastian Nozzi sebnozzi@gmail.com 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 -
On Sun, Dec 30, 2012 at 7:40 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-12-27, at 01:32, Sebastian Nozzi sebnozzi@gmail.com 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
Top post: I never once thought about that, and it makes me smile.
On Dec 30, 2012, at 7:40 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-12-27, at 01:32, Sebastian Nozzi sebnozzi@gmail.com 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 Beginners@lists.squeakfoundation.org 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" casey.obrien.r@gmail.com wrote:
Top post: I never once thought about that, and it makes me smile.
On Dec 30, 2012, at 7:40 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-12-27, at 01:32, Sebastian Nozzi sebnozzi@gmail.com 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Casey Ransberger -
Sebastian Nozzi -
Tim Retz -
Yoshiki Ohshima