Lambda the Ultimate

Fascinating stories! I'm overwhelmed! But, learning the language first, then its history. "Smalltalk 80: The Language", does it have an online PDF version? Preferrably typeset in LaTeX?

Thanks again! All that happened even before I was born! My head is spinning...

Co-routines were popular even then? I hope by "co-routine" he means functions than remember what happened the last time they were called? as in C# (2.0):

IEnumerator<int> callMeAgain() {
  yield return 0;
  yield return 1;
  yield return 2;
}

erm... does he? How would I go about implementing message dispatch using co-routines?

Smalltalk allows you to invoke a method that does not exist.
It lets you /try/. Just as a web browser lets you try to read a webpage that does not exist. Just as Java lets you try to dereference nil.

Smalltalk doesn't have the idea of functions...
Maybe you should look at those collection hierarchy enumeration methods again ;-)

It lets you /try/. Just as a web browser lets you try to read a webpage that does not exist.

Just as Java lets you try to dereference nil.

Maybe you should look at those collection hierarchy enumeration methods again ;-)

The server sees all messages, including the ones for pages that do not exist.
And that's valuable because we don't have a way to figure out which pages exist - if we could magically know before sending the request whether the request would result in a viewable page that would be just fine.

Being as nil is not an object in Java (another primitive), a method does not get called. Instead an exception is generated, which can be caught.
The default behaviour in Smalltalk also results in an exception which can be caught, the interesting thing is that in Smalltalk we can change that default behaviour, the behaviour is defined by objects and methods that we can modify - if the behaviour was defined by objects and methods that we could not modify then it wouldn't be very interesting.

I may be going out on a limb here, but I'd say that Smalltalk doesn't have functions. ...There are also code blocks, and they can be used in a similar manner to lambdas, but even the code blocks are at some level objects.
The fun and confusing thing about Smalltalk is that most of the mechanisms used in the language implementation, and the abstractions used in the libraries, and our programs are all at the same level - they are all just objects.

Most of the time, thinking that a Block is an object is thinking at the wrong level of abstraction - the fact that a Block is an object is an implementation detail. The interesting thing about a Block is that we can define anonymous computations, apply them to arguments and get results.

Chris Rathman wrote:
I put together some Smalltalk notes if you want the terse guide.

Thanks. I found this bit confusing though:
Class Instance: unique to each instance of a class

Instance Variables: unique to each instance
What's the difference? Is this relevant?

(no need for one set of logic that applies to static
methods/properties, and another that applies to instance
methods/properties).

(a message sent to an object returns an object, and a message can be sent to that returned object).
I guess this is the bit that confuses me most. Consider,

y := x indexOf: $e ifAbsent: [0].

Could you please explain the actual meaning of it? Who is the receiver of the message? x, I suppose. Does x receive both messages at once? or does (x indexOf: $e) receive ifAbsent[0]? Binary messages were mentioned a couple of time but I guess a Java programmer's intuition would be that x is the object, indexOf is the method, $e is the method argument. Then s/he gets lost if s/he is familiar with Haskell. ;-) Specially when what follows is another method. What's the point of ; operators, by the way? I'm sorry to bug you like this but my wishful thinking is that being pretty confident about these issues will help me understand Oleg Kiselyov's OO paper on Haskell. I guess it's pretty inconsiderate of me not to do my own research :-) But I thought you guys will enjoy relishing the memories anyway 8-)

Those primitive types are not superficial erm... I didn't actually mean the primitive types are superficial. What I meant to say is that treating them as 'value' types (whereas objects are all 'reference's) in Java is a superficial difference I am willing to overlook. What I gathered so far is that, since Scala treats primitive types as objects as well (via autoboxing/unboxing?) the claim that it is "pure OO" is more-or-less justified because there's nothing more to it. Inappropriate statement? The "classes are first-class objects" issue, with the reflection API in Java, seems a bit overrated to me, if you don't mind me saying that. Does Smalltalk allow runtime method redefinition? That would definitely be something... in my humble opinion Smalltalk (with duck typing, as I understand it) is a (fantastic!) scripting language!

Isaac Gouy wrote:
Most of the time, thinking that a Block is an object is thinking at the wrong level of abstraction - the fact that a Block is an object is an implementation detail. The interesting thing about a Block is that we can define anonymous computations, apply them to arguments and get results.
Erm... sound like lambda calculus to me! What messages would a block of code (as an object) understand? Could you show me with nullary, unary, and binary functions (lambdas, code blocks with local variables, whatever... I have happy with a lack of knowledge of terminology).

Cheers, and thanks!

Who is the receiver of the message? x, I suppose.
I Can Read C++ and Java But I Can’t Read Smalltalk

Download VisualWorks NonCommercial and explore!

Thanks. I found this bit confusing though:
Class Instance: unique to each instance of a class

Instance Variables: unique to each instance
What's the difference? Is this relevant?

y := x indexOf: $e ifAbsent: [0].
Could you please explain the actual meaning of it? Who is the receiver of the message? x, I suppose. Does x receive both messages at once? or does (x indexOf: $e) receive ifAbsent[0]?

With two keywords, you'd have three possibilities:

   "x receives a single message #indexOf:ifAbsent:"
   y := x indexOf: $e ifAbsent: [0].

   "x receives two messages #indexOf: followed by #ifAbsent:"
   y := x indexOf: $e; ifAbsent: [0].

   "x receives a single message #indexOf:
    then the object returned by that call receives the message #ifAbsent:"  
   y := (x indexOf: $e) ifAbsent: [0].

What's the point of ; operators, by the way?

The "classes are first-class objects" issue, with the reflection API in Java, seems a bit overrated to me, if you don't mind me saying that.

The "classes are first-class objects" issue, with the reflection API in Java, seems a bit overrated to me, if you don't mind me saying that.

Does Smalltalk allow runtime method redefinition? That would definitely be something... in my humble opinion Smalltalk (with duck typing, as I understand it) is a (fantastic!) scripting language!

so unlike Java, Smalltalk methods (messages) are 'compound'.
ifTrue: and ifTrue: ifFalse: and ifFalse: are difference messages. In Java we have one method receiving multiple parameters, in Smalltalk the message itself organizes it. Cool. I can see it's a pretty neat language design.

Hello Chris, it would be nice if you would reformat that long "pre" line so that it does not make the page width so large... Thanks!

Broke it up into some more lines (and fixed it to use the standard smalltalk symbols for message selectors).

This is probably *exactly* what I needed to know. The diagrams were crystal clear. Funny, two days of googling failed to locate that page! I should pick my keywords more thoughfully.

(or may be it's just because I didn't know the term 'metaclass')

Is there a way to represent functions (rather than methods) in Smalltalk?
Apart from this one, your Socratic method was working quite well :-| But for this one, I just don't know! Code blocks? Can a code block take another code block as an argument?

But actually I am not really after currying. I am after a functional semantics of multiple message passing.

Hmm. Makes you think, doesn't it? What exactly is "advancement"? As of today, I see three closely related interpretations, procedural, functional, and object-oriented (quite neatly covered by Perl, Haskell and Smalltalk, the choice of representatives chosen to be a bit shocking, or should I say Turing Machines, Lambda Calculus and Petri nets respectively?), and the sad part is that new languages are mostly error-correcting. This is bad. Never mind me.

Thanks for your reply. I found your examples involving C++ particularly helpful. By now, I guess I have a pretty good idea about what to look for. The question remains as to where to look for it.

Perhaps you could point me to some place where subclassing in Smalltalk is contrasted with Java's? Your explanation sounded quite alien (for a Java-savvy), I'm afraid. Can I apply this/self correspondence to super/super correspondence with confidence? Or will be it the 'biggest mistake of my life'?

Cheers and take care.

A couple of general Smalltalk vs. Java comparision pages:

Java and Smalltalk syntax compared

SmallJava: Using Language Transformation to Show Language Differences

uchchwhash: Perhaps you could point me to some place where subclassing in Smalltalk is contrasted with Java's? Your explanation sounded quite alien (for a Java-savvy), I'm afraid.

(Please forgive my use of stream-of-conscious format instead of reverse pyramid structure as if I was writing something for publication.)

I'm not Java savvy enough to do a decent job. And if I was, I'd hate to explain Smalltalk subclassing in terms of something more complex. It might be better if I just describe matters in terms of hash tables using symbols as keys. (Smalltalk symbols are like Lisp symbols: interned strings such that two symbols with the same name are in fact identically the same symbol instance. If string 'foo' is interned as a symbol, then #foo is this symbol under Smalltalk and 'foo is this symbol under Lisp.) The explanation will also sound pretty much like the way Python method dictionaries are done, so you can read about Python and get more or less the same description.

My explanation below relates what you see lexically in the grammar to what you're likely to find in the runtime data structures of resulting Smalltalk classes.

Each Smalltalk class has a method dictionary containing ordered pairs of (selector, method) entries. The method value has a type something like CompiledMethod, or whatever a particular runtime wants. The selector key has type Symbol, where a symbol is an interned string as noted above. Every time a method is defined, an entry is added to a class method dictionary with the method name as the key, and the compiled method as the value.

The term "selector" in Smalltalk means a symbol used as the name of a method, and nothing more. So if you add a unary method named 'negate' to some class, then #negate is the symbol used as the selector for that method. Selectors only fall into three classes, depending on letters in the name, corresponding to the three grammatically different ways to express a message send in Smalltalk: keyword, binary, and unary messages. (This is in order of increasing precedence.) Keyword selectors end in colons. Binary selectors are one or two special symbols from an explicit list. Unary selectors are alphanumer identifiers that don't end in colon. The arity of a unary method is one. The arity of a binary method is two. And the arity of a keyword method is one plus the number of colons that appear in the selector name. (Plus one is for the message's receiver.)

I just summarized what you can see yourself from the original Smalltalk grammar bubble diagrams, if you work out the consequences of the resulting grammar. Here I'll blockquote a sidebar on bubble diagrams:

If you buy a physical copy of one of the original Smalltalk books, the inner hardback cover is decorated with bubble diagrams covering the entire Smalltalk grammar, which is (to me) shockingly simple. I believe this is the way Smalltalk's grammar was presented to early users. (Its's fairly easy to translate the bubble diagrams into standard BNF notation, but perhaps few of the early non-technical users would have understood this notation.)

Just now I googled for "smalltalk grammar bubble diagrams" and found this page:

http://www.cs.ualberta.ca/~duane/courses/625/parser/

It has all the original Smalltalk bubble diagrams as jpegs apparently scanned from the book. But you'd best save your own local copy, since I don't see very many other hits for this material. Maybe it will vanish by the time folks read this post later.

To illustrate method dispatch, and resulting style of Smalltalk subclassing, let's consider an example. Earlier in this thread you chose the following example Smalltalk statement:

y := x indexOf: $e ifAbsent: [0].

This assigns to variable y the value returned from sending #indexOf:ifAbsent: to x, with two arguments, the character constant $e and block [0]. (Note the purpose of using a block is delayed evaluation; the only way to avoid evaluating expressions passed to a method is to put them in a block, so they won't be evaluated until someone evaluates the block.)

So your example here dispatches only one message: a keyword message named #indexOf:ifAbsent: taking two arguments plus the receiver x. (Smalltalk grammar intersperses the arguments with each section of a keyword message selector name, so a one to one corresponence results.)

When you evluate the right-hand-side, what happens is something like this. The method to be called is found by the runtime by evaluating something like the following:

(x class) methodForSelector: #indexOf:ifAbsent:

(Note I just made up the methodForSelector: name here; it's just pseudocode.) The method returned by that expression is then called with two arguments $e and [0].

A Smalltalk compiler will typically emit bytecode that actually references symbol #indexOf:ifAbsent: as a literal value in the method dispatch (unless the bytecode itself encodes the selector). So the method is effectively dispatched by name. This symbol is used as a lookup key to search method dictionaries -- presumably hash tables -- starting with the class of x and working back to superclasses of (x class) if #indexOf:ifAbsent: is not found in (x class). Each class has a pointer to it's own superclass, so searching the inheritance chain at runtime is explicit.

In practice a runtime won't want to actually search the inheritance chain of classes every time a method is dispatched, but this is easily avoided by using a lookaside cache containing the result of earlier similar dispatches. A lookaside cache might just be a large hash table with keys of format (class, selector) and values equal to methods found earlier for such searches. (Lookaside cache invalidations need only occur when new methods are added to class method dictionaries.)

This sort of dispatch and this kind of lookaside cache is often used in other similar languages like Objective C, which imitates both Smalltalk syntax and Smalltalk style method dispatch using selectors. Except Objective C probably maps selector names to integer constants at compile time, rather than using the symbols for selectors themselves. (I seem to recall having a conversation with John Anderson about this when we worked together briefly at OSAF. He was the guy who worked on optimizations in the Objective C runtime at NeXT, and he'd done something like the same lookaside cache that I'd coded into a Smalltalk I'd done in the 90's.)

Anyway, you can infer the nature of Smalltalk subclassing from a few details:

• each class has an array of member variables keyed by name/position
• each class has a table of methods keyed by selector
• each class declares it's own superclass when it is defined
• every non-primitive object has a pointer to it's own class
• (the class of every primitive type is known statically by the runtime)

Subclassing under Smalltalk just involves naming the superclass (or superclasses when multiple inheritanced is supported). Method overriding merely requires redefining a method with the same selector. The entry in the method dictionary of a subclass will be found first at dispatch time, so any other entries for the same selector in superclasses won't be found.

Smalltalk-80 didn't have private scopes for member variables, so all subclasses could see and use the members of any superclass. Using C++ terminology, all Smalltalk methods were public and all member variables were protected.