XLogo Programming Logo Turtle Graphics with XML
Dmitri Kondratiev
< [email protected] >
Created : 2/26/98
Last Modified : 3/4/98
XLogo home at < http://www.geocities.com/SiliconValley/Lakes/3767/xlogo-index.html >
XLogo is a markup language I wrote to demonstrate programming of Logo turtle graphics with XML. XLogo markup describes turtles behavior (currently simple animation) on 2D plane. XLogo program is a well-formed and valid XML document. XLogo runtime is a set of Java classes that process XLogo program and perform turtle behavior as specified by XLogo markup language elements and defined in xlogo.dtd. XLogo is an experiment in Meta Object Oriented Programming. The main reason why I wrote XLogo was to find out the advantages that XML provides for developing problem domain specific meta languages. Another goal was to learn XML and experiment with SAX - Simple API for XML.
Please send any feedback to Dmitri Kondratiev
Try XMLTurtle - XLogo simple demo applet (requires JDK 1.1.5 support in the browser). After applet starts push "Turtle Commander" button and select XLogo program from "Programs" menu in commander frame. "Options" menu allows to turn on/off output of XLogo program code when it is being parsed - "Show code" menu item or when the program runs - "Show debug" menu item. Last option ("Show debug") slows down program execution considerably and consumes a lot of resources. In next version I hope to find a better solution for "debug" mode. XMLTurtle applet uses a directory of XLogo programs that you can easily extend adding your own programs. This directory is a XML document itself that conforms to the following DTD :
<?xml encoding="UTF-8"?> <!-- The whole directory --> <!ELEMENT turtle_dir (turtle_code)*> <!-- The turtle program description --> <!ELEMENT turtle_code EMPTY> <!ATTLIST turtle_code name CDATA #REQUIRED href CDATA #REQUIRED > <!-- end of DTD --> |
Example directory :
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE turtle_dir PUBLIC "-//Dima//DTD Turtle Directory//EN" "turtle_dir.dtd"> <turtle_dir> <turtle_code name="Concurrent Turtles" href="concurrent.xml" /> <turtle_code name="Sequential Turtles" href="sequence.xml" /> <turtle_code name="Forms" href="forms.xml" /> <turtle_code name="Hello XML Turtles" href="hello-xmlturtle.xml" /> <turtle_code name="Polygons1 - demo of XLogo functions" href="polygons1.xml" /> <turtle_code name="Polygons - demo of nesting functions" href="polygons.xml" /> <turtle_code name="Square and Triangle" href="square-tr.xml" /> <turtle_code name="Functions" href="function.xml" /> <turtle_code name="test" href="test.xml" /> </turtle_dir> |
XLogo program directory is a set of turtle_code elements. The turtle_code element has two attributes :
- name - XLogo program name - arbitrary string;
- href - URL of XML document with XLogo program. (See note)
<applet code="dk.xml.xlogo.XMLTurtle.class" archive="xlogo.jar" width=400 height=400> <!-- Change "turtle_dir.xml" to the URL of your own XML Turtle Directory --> <param name="TURTLE_DIRECTORY" value="turtle_dir.xml"> <param name="HELLO_WORLD" value="hello-xmlturtle.xml"> </applet> |
- TURTLE_DIRECTORY specifies URL of turtle directory XML document.
- HELLO_WORLD specifies URL of XML document with "Hello World" XLogo program. "Hello World" program is the first program that XMLTurtle applet runs when it starts on the page.
Note:
All XML document URLs are relative to HTML document with XMLTurtle applet tag. Turtles are the main objects that XLogo operates with. With XLogo you can program both sequential and concurrent animation of a number of turtles. XLogo main elements are :
- xlogo - the whole Xlogo program that may contain the following elements :
- turtle - describes turtle animation that may include one or more :
- pen, fd, bk, rt, lt - turtle drawing command elements
- to - method invocation element
- cmd - turtle method declaration element
- repeat and list elements
- fork - contains one or more turtle execution threads thus enabling spawning of one or more concurrent turtles :
- thread - turtle execution thread that may in turn contain other fork or turtle elements.
- cmd - turtle method definition that must start with formal parameter declaration provided by arglist or arg element and may contain one or more :
- pen, fd, bk, rt, lt - turtle drawing command elements
- to - method invocation element
- repeat and list elements
To enable concurrent turtle behavior XLogo provides fork element which allows to spawn one or more concurrent turtles defined in the thread elements that fork element contains. The defPriority attribute of fork element may be used to set default priority for all turtle threads it contains. This default priority may be overwritten in thread element by specifying priority attribute value for each turtle individually. In its turn thread element may itself contain fork elements. These elements together with turtle element make possible to specify a wide variety of turtle concurrent and/or sequential animation sequences.
Currently XLogo supports only static methods shared by all turtle objects, similar to Logo procedures. Thus static turtle method can be defined with cmd element anywhere in xlogo element. Methods are specified by a pair of to and cmd elements. The to element is a method invocation and cmd element is a method definition. Method invocations may be nested in method definitions. To bind method invocation to its definition attribute name is used both in to and cmd elements. Thus to and cmd elements with the same value of the name attribute refer to the same method. To pass parameters from method invocation to its definition, arg element is used in the body of to and cmd elements. The arglist which is a set of arg elements specify formal parameter declarations when used in cmd context and actual arguments when used in to invocation.
In the body of cmd element special syntax is used to refer to formal parameter in the method declaration. Anywhere where substitution of formal parameter in the method body is needed, the reference to the formal parameter with name "foo" in the arg element is specified as "#foo".
For example:
<!-- Draw sequence --> <cmd name = "sequence"> <arglist> <!-- Default arguments to draw sequence --> <arg name="repeat" value="60"/> <arg name="side" value="40"/> <arg name="angle" value="6"/> <arg name="offset" value="10"/> </arglist> <repeat cnt="#repeat"> <to name = "polygon"> <arglist> <arg name="length" value="#side"/> </arglist> </to> <pen state="up"/> <rt angle="#angle"/> <fd length="#offset"/> <pen state="down"/> </repeat> </cmd> <!-- Procedure to draw polygon. --> <!-- Arguments: numberOfSides - number of polygon sides length - side length angle - angle between two sides --> <cmd name = "polygon"> <arglist> <!-- Default arguments to draw square --> <arg name="numberOfSides" value="4"/> <arg name="length" value="60"/> <arg name="angle" value="90"/> </arglist> <repeat cnt="#numberOfSides"> <list> <fd length = "#length"/> <rt angle = "#angle"/> </list> </repeat> </cmd> |
Currently XLogo supports the standard set of Logo drawing commands : pen, fd, bk, rt and lt. The fd and bk commands move the turtle forward and backward respectively, in the direction that it's headed, by the specified distance (measured in turtle steps) and set by 'length' attribute.
The rt command turns the turtle clockwise and lt - turns it counterclockwise by the specified angle, measured in degrees (1/360 of a circle) and set by 'angle' attribute.
The 'state' attribute of pen command sets the pen's state to down or up and 'color' attribute sets pen color to the specified RGB value, where the red component is in bits 16-23 of the argument, the green component is in bits 8-15 of the argument, and the blue component is in bits 0-7.
The repeat element contains XLogo commands to run repeatedly, with 'cnt' attribute specifying repeat count. It may contain to, list, repeat, pen, fd, bk, rt and lt elements. The most convinient usage of repeat is together with list element such as :
<repeat cnt="8"> <repeat cnt="8"> <list> <fd length = "20"/> <rt angle = "45"/> </list> </repeat> <rt angle = "45"/> <bk length = "60"/> </repeat> |
XLogo is an experiment aimed to answer just this question. The main reason I've chosen Logo is because it balances well the power of functional programming language, such as list processing, that comes from Lisp, with ease of expressing simple things. I believe that some of the functional programming concepts will be a foundation of Meta Objects, which I see as a next step in OOP evolution. It seems to me that "data == code" concept would be central in Meta OOP.
SGML provides fundamental notation necessary to describe metadata constructs and XML makes implementations of basic metada simple to design. Both SGML complexity and XML simplicity have their cost, though. Looks like proposed so far metadata solutions for SGML/XML, such as RDF, MCF, XML-Data, Name Spaces in XML and SGML Architectures address metadata requirements only to some extent.
The main goal of XLogo is to provide environment for Meta OOP research, that will allow to create effective and "clean" mechanisms for meta object reuse and inheritance. Meta OOP constructs in XLogo are expressed in XML, which becomes widely accepted standard for various metadata frameworks/schemas of today.
I agree that right now my work doesn't give direct answers to Meta OOP questions. However, I hope to demonstrate (in the future releases of XLogo) the main strength I see in meta programming :
- runtime component introspection which will make dynamic distributed component frameworks possible;
- specification of component aspects on meta level, or - meta aspects, that are independent from component processing language;
Already in the current release of XLogo one can introspect XLogo program (<xlogo>...</xlogo>), which is in fact a container/context for <turtle> meta objects. Lets say we have some "Turtle Web Search" engine that use introspection of XLogo objects and allows you to find turtles or containers full of turtles (<xlogo> programs, in other words "turtle ponds") according to some criteria. XLogo <fork>, <thread> and <turtle> elements allow to search for "ponds" with concurrent and sequential turtles as well as any combination of these. Besides you can search for turtles with some default attribute value such as turtle color.
To say more, having turtle behavior described in XLogo as a simple animation specified in a concise set of drawing/movement commands (fd, bk, rt, lt and pen), a more sophisticated search tool can be built to search for turtles with some "behavior patterns". Logo, being from the lisp family of AI languages is an excellent example of expressive power/simplicity combination. For example, a query like "all turtles drawing triangles and squares but not circles" becomes possible. Thus we have primitive behavior introspection !
With XLogo I try to make an example of extending Aspect-Oriented Programming concepts introduced in Xerox PARC AOP project to metadata and Meta OOP. This XLogo release doesn't have explicit aspect specification syntax. Still <fork> and <thread> elements are good candidates for this in the future. In fact, these elements specify aspects of turtle behavior in containing program/context ("pond" object). Besides, turtles themselves will have aspect constructs that should make possible to effectively expose those turtle properties that are hard to describe in traditional prog. language. By "hard to describe" I mean hard to describe to the outside world, not hard to provide internal to turtle object specification. Yes, the main reason for aspects, as I see it, is to facilitate introspection and thus dynamic composition. What should be described as aspects ? I think, both:
- general to most domain things, such as object method synchronization policy, object persistence policy, etc.
- problem domain specific things, for example, in turtle case this might be different turtle characteristics, such as "favorite occupation", "laziness" etc.
Why not to use a regular object property for this instead of "fuzzy meta aspects" ?
I think I have an answer : regular object property is specific to programming language and thus hard to understand for other tools. Meta aspect property should have more "representational" power, I believe. This doesn't mean, of course, that all object properties should be treated as meta aspects - only those that are shared among different, independent tools and may be, in some cases, even different problem domains .
It seems important to note here dynamic meta aspect nature. By dynamic I mean not only changing in time aspect value, such as synchronization policy depending from changing environment/context, but also aspect addition and removal during meta object lifetime. So, again we come here to dynamic composition, but this time on a different scale, instead of "simple" interfaces we may compose aspects !
Looking at turtle world this way will allow to do a lot of interesting things. Not only "turtle search" tools may provide better result analyzing pond and individual turtle aspects. Dynamic, distributed turtle framework consisting of turtle ponds/contexts may be created. Having such a framework, agent-turtles may exhibit primitive behavior moving from one pond to another, introspecting environments and pursuing some goal, such as finding a 'good' pond with 'friendly', 'lazy' turtles moving in circles. This may all sound crazy, I know, but as I said XLogo is an experimental project, Meta Playground or XML Diversion - whatever you like.
Currently XLogo supports only static methods shared by all turtles, similar to Logo procedures. Next I plan to add meta-object instance methods and meta class specification. I want to have general enough MetaClass (not only for turtles :) as a super class for turtle class (also meta).For the networking part, I am considering now UberNet, Swarm, Voyager and even thinking about making my Active Bean Space to work in XLo