Software Engineers Handbook/Language Dictionary/ToonTalk
- 1 ToonTalk
- 1.1 Type
- 1.2 Execution Entry Point
- 1.3 General Syntax
- 1.4 Comments
- 1.5 Variable Declarations
- 1.6 Method Declaration/Implementation
- 1.7 Scope
- 1.8 Conditional Statements
- 1.9 Looping Statements
- 1.10 Output Statements
- 1.11 Containers
- 1.12 Algorithms
- 1.13 Garbage collection
- 1.14 Physical Structure
- 1.15 Tips
- 1.16 Web References
- 1.17 Books and Articles
Ken Kahn invented and implemented ToonTalk and proposes it for children. It is available for free from the ToonTalk web site to run under Windows on Intel-type architecture. I don't know whether anyone has tried it on a Windows emulator over a Unix-like system.
ToonTalk has fine-grained concurrency and arguably a declarative interpretation, as a concurrent constraint (logic) language. Arguments are objects, not in the "object-oriented" programming sense of "object", but in the more everyday sense in that if I hand you an object, I don't have it anymore.
Execution Entry Point
The programmer triggers execution by performing a manipulation. There is no particular place to which this is limited.
ToonTalk's syntax is animation, as in cartoons. The programmer takes on a persona and shows robots what to do by example. The programmer (or a robot) can assemble robots into teams of robots. Giving a team a box (an array/tuple container) starts a process. Order matters in the team. On each execution cycle of the process, the robots in sequence attempt to match a pattern (one pattern per robot) to the box. The first match fires.
The programmer or a robot can put an object in a "hole" (compartment) in a box, or can take it out. You may regard this as similar to assignment. Holes can be empty.
A magic wand is available to copy things, and a vacuum cleaner is available to make things go away.
There is one reference and communication structure, consisting of bird/nest pairs (or families). A bird flies to a nest, in the simplest case (it is also possible to have multiple birds fly to the same nest, one bird fly to multiple nests, or multi-to-multi, but for this description, I'll continue assuming the simplest communication). When the programmer or a robot gives an object to a bird, the bird (she; all birds are female and all robots are male) flies to her nest and deposits the object there. If there are any objects already on the nest, the bird puts the new object underneath them.
When a robot is waiting for an object of a particular type to be in a hole in a box, if there is in fact an uncovered nest in that hole, the robot waits until a bird should put something on the nest. Then, the box appears to the robot as though the delivered object were there instead of the nest. Consequently, you can pass structures (as boxes with possible nested boxes) with, in effect, parameters whose values are not known yet, represented as nests. When another part of the program figures out what the value of the parameter should be, it can hand an object representing that value to the bird that flies to the nest in question.
You may regard handing an object to a bird as similar to assignment.
Actually, I lied; the bird and nest is not the only reference structure. There are also "sensor" objects linked to other objects as their "looks", and changes to one are immediately reflected in the other. These can't be boxes, however, just text, numbers, or pictures. I consider sensors dirty in the sense that assignments are dirty in Lisp and you can think of "pure Lisp" as a dialect free of this dirt. However, the sensors seem to be necessary in ToonTalk practice as part of an output mechanism (animated "pictures") that would be awkward to drive with birds; Dr. Kahn experimented with having birds as the only I/O and eventually switched to using the sensors.
The programmer or a robot can type labels on holes, birds and nests, and robots. The labels have no effect on execution, but can help the programmer very much to remember what the holes are for in the design. Also, the reportoire of objects includes "notebooks" on which it is common practice to write documentation as text pads placed on the left page to document whatever object is stored on the right page that follows. A notebook as a whole can also be labeled.
A box has a number of holes. You can put any object in a hole that is not already occupied. You can also hand a "rectangular" object (such as a box, a number pad, or a text pad) to a bird. The presence of the hole or bird could be said to constitute a declaration of a variable. The logic behind such a thought would argue that you can think of putting an object in a hole as assigning a value, and so the hole represents the potentiality to determine that value, and that is what a variable fundamentally is; it's an entity whose value we may not know yet, but to which a value can be assigned once we have figured out what it ought to be. From this viewpoint, the value of a bird could be thought of as the sequence of objects that will eventually be given to the bird.
On the other hand, if we choose to think of any object in ToonTalk that gets modified as two distinct objects, the one before the modification and the version after, then we can see the language as declarative and so of course there are no assignments nor variables to declare, except logical variables, and a bird/nest pair could be thought of as a logical variable. When you extract the bird/nest pair from Tooly the Toolbox, you are declaring the variable.
It's a matter of viewpoint.
There is a "toolbox" (really a supplies box) available to the programmer and all robots in all contexts. The programmer takes a fresh robot from the toolbox and hands it an example box. Each robot sports, at all times, a comic-book style "thought bubble", which reveals what pattern the robot would try to match (always a box) (a fresh robot has a thought bubble without any box in it; this is referred to as a "robot without a thought"). The programmer (in this case, a robot can't do this) gives an example box to a fresh robot as just taken from Tooly, the toolbox (the tools all have cute names; the magic wand is Maggie and the vacuum cleaner is Dusty). The animation then expands the robot's thought bubble to fill the screen. It is populated with a copy of the example box, and with the toolbox, and with an image of the robot that is connected to the mouse as its cursor. The programmer uses this cursor to act out what the robot should do every time it fires. To finish up writing the method, the programmer has two choices exactly. One is to hit the ESC key. When the robot executes this action, the process of which it is a part continues in existence and proceeds to its next cycle of execution. The other exit syntax is to pick up a bomb and explode it. This destroys the process when executed. Note that the programming session is not an execution, except in a limited sense that calculations on the visible objects will have their results evident.
After the programmer has thus specified the robot's actions (or body or tail as I would call it, thinking of the robot as a rule in a logical language), the programmer (or a robot, I think) can generalize the robot's pattern to the degree required by the software design.
Robots can manipulate the objects that are convenient to hand. The robot finds these objects in its "My Box" and can temporarily put them on the floor. "My Box" can also be manipulated (e. g. given to a bird).
Robots do not wander around.
There are three forms of action at a distance. One is the bird/nest mechanism already described above. The second is the spawning of new processes. A third involves special "sensor" objects that have immediate effects on their remote correspondents; I don't like to talk about them; they're dirty.
When a robot or the programmer hands a message (any "rectangular" object) to a bird, after the bird delivers the object to her nest, the bird flies back, and it is possible to hand her additional messages, or to pass her off to somebody else who can do so (e. g. by putting her in a hole in a box and handing the box to another bird).
The only conditions are those that are checked by the robot pattern matching mechanism described above. The body of a robot is straght-line code with no conditions, loops, or subroutine calls. Thus no stack is required for execution, and the time to fire a robot is predictable and short.
Patterns can directly check object type (e. g., number, string, N-hole box (with possible pattern constraints on what can be in the holes), box generally without regard to number of holes, bird, empty nest) and can check for constant values of numbers and strings (thus a string can serve as a message selector). To do magnitude comparisons (<, >), it is necessary to employ a balance. The balance compares two numbers or strings that are on either side of it in a box, and a pattern can look for a balance in a given aspect of tilt (less than, equal, or greater than).
Each process that does not blow up is always in a loop. Recursion is also possible by spawning additional processes, which can contain a copy of the robot team that spawns them, or any other robot team. There is no other looping mechanism. In particular, as mentioned above, the body of a robot is staight-line.
Suppose you have been given a bird, and your understanding is that you are to use that bird as your output channel. Then extract a text pad from Tooly. While holding or pointing to the text pad, hit the backspace key to get rid of the "A" that is there (all fresh text pads have the single character "A" on them). Then type "Hello world." Press enter if you would like to include a carriage return. Hand the modified text pad to the bird.
There are also "pictures", which can have robots on the back of them executing as processes and causing the picture to change appearence (including showing text) using sensor objects associated with the picture. The programmer may thus animate characters.
The programmer can travel around the system and observe any process or object, and manipulate them besides.
The native container is the box. A box is a linear arrangement of zero to 64K - 1 holes. A hole can contain any object or be empty. Note that a box can contain another box. Boxes can be appended to each other or broken up. The zero-hole box is possible and useful.
Note that a list structure can be built of two-hole boxes. This differs from a Lisp list in that no objects can be shared between lists (except, in effect, birds and nests).
Note that processes can be used to contain things (every process centers around a single box, called "My Box"), and linked structures can be built up of processes communicating via birds and nests.
Algorithms tend to be recursive.
There is no automatic garbage collection. Each process (except the ones on the backs of pictures) occupies a "house". The programmer is responsible to decide when these are no longer needed and arrange for them to blow themselves up.
The dynamic space for systems being run and modified by a user/programmer is called a "city". A city consists of a 2-d array of city blocks with streets and avenues running between them. Four houses can be built on each block. A helicopter is available to give the programmer an overview and to support quick movement around the city. On entering a house (on foot), the programmer can observe the contents, which is usually a process. A programmer can also leave objects around in houses (or even on the grass outside, but this is not very useful, as not all manipulations will work from there). Processes are blind to whatever a programmer may have left in their respective houses, and an execution cycle of a process cannot leave anything behind, either (other than "My Box" and its contents). When a process spawns another process, this is done by the robot extracting a fresh truck from Tooly (it looks like a toy truck) and placing on it a team of robots (a single robot is really a one-robot team, and there is no way to construct a zero-robot team) and a box. As soon as the truck is loaded with both these ojects and is sitting on the floor of the house, it drives away. Once outside, it grows to the size of a real truck (so it appears in the animation, anyway) and drives around looking for a place to build a house. An invisible crew of house builders emerges from the truck and builds the house very quickly. The truck then shrinks to toy size again and drives into the house. The truck then disappears, leaving the team of robots to work on the box.
It is possible for the programmer to save a city on a Windows file, and to resume execution with a copy of that city. It is possible for the programmer to export or import any object (the export format is XML). There are long-distance birds that can fly over the Internet to different running instances of ToonTalk. There are "notebooks" that hold copies of objects on their pages (which can include notebooks). Every programmer has a principal notebook, which is persisted between ToonTalk sessions. It is here that one usually saves robots as soon as they are defined. These mechanisms, with the exception of the long-distance birds, are only available to the programmer by direct manipulation; robots cannot do them. Robots have no access to a persistency mechanism except through "foreign birds" (not to be confused with long-distance birds), which constitute the interface between languages.
<Please include tips that make it easier to switch to this language from another language.>
It may be best not to have been exposed to other programming languages.
But some basic computer science still applies. Recursion is still recursion, and data structures are still data structures.
If you want to program with a stack, you can make your own.
Books and Articles
<List additional books and articles that may be helpful. Please include for what level reader the references are appropriate. (beginner/intermediate/advanced)>
Morgado, Leonel; Kahn, Ken (2008). Towards a specification of the ToonTalk language, Journal of Visual Languages & Computing, 19 (2008), 574-597.
Main list of papers: