Previous | Table of Contents | Next |
The language itself mixed objects with functions (Goldberg & Kay, 1976). The following are some sample expressions:
As you can see, Smalltalk-72 used a number of special iconic characters, such as a pointing finger preceding a name to signify the literal symbol rather than its value, and the smiling face to denote the line-drawing turtle named smiley (graphics using turtles was adopted from LOGO). Control structures were represented as functions (such as repeat [ ], done, done with <value>, again, for, and do n [..]). The following symbols were used to denote the special ways in which an object could parse a message stream:
![]() | Eyeball. Answer not-false if a specific word appears as the next word in the message. |
![]() | Open colon or uneval bind. Receive the next literal token (single word or words enclosed in parentheses) from the message. |
![]() | Closed colon or eval bind. Receive the next value from the message. |
![]() | Keyhole. Same as uneval bind, except the current place in the message stream is retained (a kind of peek ahead). |
![]() | Right arrow. The conditional of the form if-clause ![]() |
Smalltalk-72 had classes and instances but no class hierarchy. You use the following syntax to create a class:
to <class name> <temporary variables> | <instance variables> | <class variables> (messages and responses)
You create an instance of a class with an expression in this form:
where <value> refers to a class. Classes implemented isnew to specify what to do when first creating an instance. Classes implemented s (apostrophe+s) to access an instance variable value or to assign a new value to that variable. Classes implemented is to answer whether an instance is a member of a class. The name SELF referred to the current object in control of parsing the message stream (the message receiver). When the programmer wanted to force a new message receiver, sequences of message expressions were separated by a period. For example, a partial implementation of a class that describes a graphical box follows (using a turtle as the drawing pen, and assuming a single window in which the turtle draws):
To box var | turt size | ||
(isnew ![]() ![]() ![]() | ||
turt place 100 150. | ||
SELF draw.) | ||
![]() | ![]() | (do 4 (turt go size turn 90)) |
![]() | ![]() | (SELF undraw. : . SELF draw.) |
![]() | ![]() | (SELF redraw turt penup go ( : ) pendn) ) |
So, if we make joe a box
then
joe draw move 50
is interpreted as joe sees draw and so tells its turtle to draw a square with each side size long. The method for draw defaults to returning joe, so joe still has control and with its eyeball sees move. The method for move asks joe to redraw. The closed colon symbol (:) in the method for redraw denotes a request to evaluate the next expression, which in this case is the rest of the move method turt penup go (:) pendn. That is, the method for redraw parses the rest of the message stream found in the method for move. So evaluating the expression has the boxs turtle lift up its pen to go some distance without marking the display surface, and then put down the pen. The closed colon in the method for move evaluates the number 50 in the original message stream.5
5I have to confess that I was not excited about Smalltalk-72 as a language for everyone. The idea that everyone could be taught how to write parsers, with nested stacking of the current message stream, was frightening.
The two consequences of the Smalltalk-72 model for dynamic binding and syntax-directed interpretation made Smalltalk-72 (and Smalltalk-71 as well) both clever and somewhat incomprehensible. First, the method invoked when a message was sent to an object could itself describe changes to an object definition, thereby dynamically altering the meaning of an expression in the language. Second, an expression that was well formed syntactically might not be well defined semantically. From the syntactic elements alone, it was not possible to infer the type of the object and therefore how it would or could respond to the message. Robust runtime exception handling was consequently a significant requirement if the system was to be used by everyone.
In this fourth iteration of the Smalltalk invention, LRG researchers implemented applications for text editing, free-hand drawing, animation, and music editing. The goal was to write as much as possible in Smalltalk itself. The more code that was written in Smalltalk, the more the Dynabook owner could directly control. Probably the most innovative of these applications was Mighty Mouse, a first-of-its-kind direct-manipulation text editor created by Larry Tesler.
The LRG research goal was to find the best combination of language definition, tools, and existing objects that could be combined by Smalltalkers to create information-manipulation kinds of applications. The mantra was that simple things should be easy to create, and hard things should still be feasible. This vision was to be realized more by creating a language whereby its users could create their own tools than by providing a finished toolbox. The compelling research question, though, was, Simple for whom? Feasible by whom? The target audience for Smalltalk was everyone, and everyone included young children as well as adults not interested in becoming programming professionals. With the availability of the Altos, it was now possible to begin research on whether children could learn to program in Smalltalk and how they could benefit from this knowledge.
Previous | Table of Contents | Next |