<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Virtual machine design -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Mon, 19 Apr 1999 22:39:07 -0700 -->
<!--X-Message-Id: 199904201407.JAA19470@dfw-ix5.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: thandor#donut,dhis.org -->
<!--X-Reference: 19990417150925.A3961#donut,dhis.org -->
<!--X-Reference: E10Z15o-0005mp-00#koala,kanga.nu -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Virtual machine design</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00089.html">Previous</a>
| <a href="msg00091.html">Next</a>
]
Thread:
[ <a href="msg00087.html">Previous</a>
| <a href="msg00061.html">Next</a>
]
Index:
[ <A HREF="author.html#00090">Author</A>
| <A HREF="#00090">Date</A>
| <A HREF="thread.html#00090">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Virtual machine design</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Virtual machine design </LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Tue, 20 Apr 1999 10:07:12 -5</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On 18 Apr 99,, claw#kanga,nu wrote:
> On Sat, 17 Apr 1999 15:09:26 +1000
> Shane King <thandor#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: <A HREF="http://www.toontalk.com/English/papers.htm">http://www.toontalk.com/English/papers.htm</A>>
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#,ix.netcom.com *--
--* Mud Server Developer's Page <<A HREF="http://pw1.netcom.com/~jlsysinc">http://pw1.netcom.com/~jlsysinc</A>> *--
--* 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#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00059" HREF="msg00059.html">Re: [MUD-Dev] Virtual machine design</A></STRONG>
<UL><LI><EM>From:</EM> Shane King <thandor#donut,dhis.org></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00089.html">RE: [MUD-Dev] Virtual machine design</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00091.html">RE: [MUD-Dev] Virtual machine design</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00087.html">Re: [MUD-Dev] Virtual machine design</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00061.html">Re: [MUD-Dev] Virtual machine design</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00090"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00090"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Virtual machine design</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00059" HREF="msg00059.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Shane King <a href="mailto:thandor#donut,dhis.org">thandor#donut,dhis.org</a>, Sat 17 Apr 1999, 05:09 GMT
<UL>
<LI><strong><A NAME="00062" HREF="msg00062.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Sat 17 Apr 1999, 16:33 GMT
<UL>
<LI><strong><A NAME="00074" HREF="msg00074.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
claw <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Sun 18 Apr 1999, 17:09 GMT
</LI>
<LI><strong><A NAME="00087" HREF="msg00087.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Alex Stewart <a href="mailto:riche#crl,com">riche#crl,com</a>, Mon 19 Apr 1999, 19:02 GMT
</LI>
</UL>
</LI>
<LI><EM>Message not available</EM><UL>
<LI><strong><A NAME="00090" HREF="msg00090.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 20 Apr 1999, 05:39 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00061" HREF="msg00061.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sat 17 Apr 1999, 16:33 GMT
</LI>
<LI><strong><A NAME="00063" HREF="msg00063.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Oliver Jowett <a href="mailto:icecube#ihug,co.nz">icecube#ihug,co.nz</a>, Sat 17 Apr 1999, 16:34 GMT
</LI>
<LI><strong><A NAME="00077" HREF="msg00077.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Petri Virkkula <a href="mailto:pvirkkul#iki,fi">pvirkkul#iki,fi</a>, Sun 18 Apr 1999, 17:22 GMT
<UL>
<LI><strong><A NAME="00082" HREF="msg00082.html">Re: [MUD-Dev] Virtual machine design</A></strong>,
Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Mon 19 Apr 1999, 08:01 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>