Two questions about Smalltalk language design

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

1) Why do ST methods return "self" if nothing is explicitly returned?

Blue book talks of:

extent: newExtent

corner <-  origin + newExtent

Bytecode:
Rectangle extent:
0 push the value of the receiver's first instance variable (origin) onto the
stack
16 push the argument (newExtent) onto the stack
176 send a binary message with the selector +
97 pop the top object off of the stack and store it in the receiver's second instance
variable (corner)
120 return the receiver as the value of the message (extent:)

For blocks:

"Since a block's expressions may not have been evaluated when it returns from fork, the value of fork must be independent of the value of the block's expressions. A block returns itself as the value of fork."

also:
http://www.mirandabanda.org/bluebook/bluebook_chapter28.html#ReturnBytecodes28

Semantically in a pure OOPS land sending a message to an object returning a nil / void may seem not so object oriented either. Message modifies or actions something on the object, the default return of the object seems sensible option to return nil

Facilitates I believe the easy operation of chaining method sends without each time having explicitly to return the object in each of those methods. viz: Aircraft airforceOne flyToDestination haltForRefuelling returnToStation. or its other forms with bracketed keyword messages. Though using cascades one can do similar stuff but will read less english like.

2) In Collections, why does "add:" return the object being added, and
not "self"?

Blue Book:

"Note that the add: and remove: messages answer the argument rather than the collection itself so that computed arguments can be accessed."

I have always pondered why this is essential and returning the collection would be fine..or return true / false rather than argument / exception, infact for Set new add: 2; add: 2 . will return 2.. though the second one does not add anything to the Set.