[MUD-Dev] Virtual machine design

[Jon A. Lambert]

On 18 Apr 99,, claw at kanga.nu wrote:
> On Sat, 17 Apr 1999 15:09:26 +1000 
> Shane King <thandor at donut.dhis.org> wrote:
> 
> > I want common users to be able to code in a real language
> > though. :)
> 
> What is a "real language"?
> 

"In the design of programming languages one can let oneself be guided    
primarily by considering 'what the machine can do.' Considering, however,    
that the programming language is the bridge between user and the machine -- 
that it can, in fact, be regarded as his tool -- it seems just as important   
to take in consideration 'what Man can think.'" - Dijkstra      

Here is an interesting look at a possible form that a user programming 
language could take.

"ToonTalk - An Animated Programming Environment for Children"   
 Ken Kahn   
 see <URL: http://www.toontalk.com/English/papers.htm>   

An Exerpt:
--cut--   

ToonTalk -- the language and metaphor.   

Video games, especially adventure and role-playing ones, place the user in an 
artificial universe.  The laws of such universes are designed to meet 
constraints of game play, learnability, and entertainment.  While playing 
these games the user learns whether gravity exists, if doors need keys to 
open, if one's health can be restored by obtaining and consuming herbs, and so 
on.  What if the laws of the game universe were designed to be capable of 
general purpose computing, in addition to meeting the constraints of good 
gaming?   

It seems that no one has ever tried to do this. (And when we figured out how 
to, we applied for a patent on the invention.) Rocky's Boots and Robot Odyssey 
were two games from The Learning Company in the early 1980s that excited many 
computer scientists.  In these games, one can build arbitrary logic circuits 
and use them to program robots.  This is all done in the context of a video 
game.  The user persona in the game can explore a city with robot helpers.  
Frequently in order to proceed the user must build (in an interactive animated 
fashion) a logic circuit for the robots to solve the current problem.  
ToonTalk is pushing the ideas behind Robot Odyssey to an extreme, capable of 
supporting arbitrary user computations (not just the Boolean computations of 
Robot Odyssey).    

There has been much research on demonstrative or programming by example   
systems.  Perhaps the earliest was Pygmalion, built in the mid 1970s by David  
Canfield Smith as part of his doctoral thesis [Smi75].  He even spoke of 
programs as "movies".  But there was no animated game-like world in which the 
programmer operated.  Instead, icons and menus were selected and a sequence of 
such selections could be iconized. Computer scientists strive to find good 
abstractions for computation.  Here, in addition, we are striving to find good 
"concretizations" of those abstractions.  The challenges are twofold: to 
provide high-level powerful constructs for expressing programs and to provide 
concrete, intuitive, easy-to-learn, systematic game analogs to every construct 
provided.  After all, a Turing Machine is both concrete and a universal 
computing formalism.  (Alan Turing strove not just for mathematical computing 
formalisms but  for their concrete analogs as well.)  One can imagine a Turing 
Machine game that in theory supports the construction of arbitrary 
computations,  but I can't imagine using it to build real programs. The 
ToonTalk world resembles a twentieth century city.  There are helicopters,   
trucks, houses, streets, bike pumps, toolboxes, hand-held  vacuums, boxes, and 
robots. Wildlife is limited to birds and their nests.  This is just one of 
many consistent themes that could underlie a programming system like ToonTalk. 
A space theme with shuttle craft, teleporters and the like would work as well. 
So would a medieval magical theme or an Alice in Wonderland theme. An entire 
ToonTalk computation is a city. Most of the action in ToonTalk takes places in 
houses.  Communication between houses (and to built-in capabilities) is   
accomplished by birds (kind of like homing pigeons).  Birds accept things, fly 
to their nest, leave them there, and fly back.  Typically houses contain 
robots that have been trained to accomplish some small task.  Robots have 
thought bubbles that contain pictures of what the local state should be like 
before they perform their task.  Local state is held in cubby holes (i.e., 
boxes).  Cubbies also are used for messages and compound data (i.e., tuples).  
If a robot is given a cubby containing everything that is in its thought 
bubble, it will proceed and repeat the actions it was taught.  Abstraction 
arises because the picture in the thought bubble can leave things out and it 
will still match.  A robot corresponds roughly to a method in an object-
oriented language or a conditional.  A line of robots provides something like 
an "if then else" capability.  Animated scales can be placed in a compartment 
of a box.  The scale will tip down on the side whose neighboring compartment 
is greater than (or if text, alphabetically after) the compartment on the 
other side.  By placing scales tipped one way or another the conditionals can  
include less than, equal or greater than tests. (Example uses of these  
concretizations can be found in later sections.)  Synchronization is 
accomplished in ToonTalk by the fact that if a robot is given a cubby and its 
thought bubble includes items that aren't yet  in the cubby it will wait 
around until those items appear.  In particular, an empty hole may be filled 
or a nest in a hole may be covered by an item by a bird.  If the robot expects 
to be given a particular kind of cubby (e.g., a  box holding the number zero) 
and another item is in the cubby (e.g., the number one) then it will give the 
cubby to the robot behind it in line. The behavior of a robot is exactly what 
it was trained to do by the programmer.  This training corresponds in 
traditional terms to defining the body of a method or clause.  

The actions possible are:
 	- sending a message by giving a box or pad to a bird,
 	- spawning a new agent by dropping a box and a team of robots into a truck 
      (which drives	off to build a new house),
   	- performing simple primitive operations such as addition or    	       
      multiplication by building a stack of numbers (which are combined by a   
      small mouse with a big hammer),
 	- copying an item by using a magician's wand,
 	- terminating an agent by setting off a bomb,
 	- changing a tuple by taking items out of compartments of a box and        
      dropping new ones in.   

These correspond to the permissible actions of a concurrent logic programming  
agent or an actor [KS90a, Agh87].  The last one may appear to a computer   
scientist to introduce mutable data structures into the language which are 
known to introduce much complexity to parallel programs. Since boxes, however, 
are copied, not shared, this is not the case.  An apparently destructive 
operation on a private copy is semantically equivalent to constructing the 
resulting state from scratch.  But the destructive operation is often more 
convenient.  In situations where there would be a performance penalty from 
unnecessary copying of boxes, a house can be built to hold a single copy and 
sharing can be  accomplished by copying birds which deliver requests to a nest 
in that house. When the user controls the robot to perform these actions, she 
is acting upon concrete values.  This has much in common with keyboard macro 
programming and programming by example [Smi75]. The hard problem for 
programming by example systems is how to abstract the example to introduce 
variables for generality.  ToonTalk does no induction or learning.  Instead 
the user explicitly abstracts a program fragment by removing detail from the 
thought bubble.  The preconditions are thus relaxed.  The actions in the body 
are general since they have been recorded with respect to which compartment of 
the box was acted upon, not what items happened to occupy the box. If a user 
never turned off their computer nor wanted to share a program with another 
then this world with houses, robots, etc., would be adequate.  To provide 
permanent storage we have introduced notebooks into ToonTalk. A programmer can 
use notebooks to store anything they've built. Notebooks can contain notebooks 
to provide a hierarchical storage system.  Notebooks provide an interface to 
the essential functionality of the file system without leaving the ToonTalk 
metaphor.  The initial notebook contains sample programs and access to 
facilities like animation and sounds. One can understand ToonTalk completely 
in its own terms.  E.g., a bird, when given something, flies to its nest, 
leaves the item there and returns.  This is how kids typically understand it.  
Computer scientists, however, might like to understand the relationship 
between computation and these ToonTalk objects and activities.  Here's the 
mapping between computational abstractions and ToonTalk's computational 
concretizations: 

Computational                       ToonTalk   

computation                         city
agent (or actor or process or object)     house
methods (or clauses or program fragments) robots (with thought bubbles)
method preconditions                contents of thought bubble
method actions                actions taught to robot inside thought bubble
tuples (or arrays or vectors or messages)  cubbies
comparison tests                    scales
agent spawning                      loaded trucks
agent termination                   bombs
constants                           number pads, text pads, pictures
channel transmit capabilities       birds
channel receive capabilities        nest
program storage                     notebooks

--endcut--  


--
--*     Jon A. Lambert - TychoMUD       Email:jlsysinc at .ix.netcom.com      *--
--*     Mud Server Developer's Page <http://pw1.netcom.com/~jlsysinc>      *--
--* I am the Dragon of Grindly Grund, but my lunches aren't very much fun, *--
--* For I like my damsels medium rare, And they always come out well done. *--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev