Repository navigation
Representational shift considerations
The following proposals are inspired by Scratch- related environments as well as by Matatalab's tangible materials, particularly their use of item connectors. The term visual syntactic programming is used here instead of "block programming" to retain a clear notion of blocks as compound statements (Heller 2026, pp. 2-4). It is understood as an activity rather than a paradigm, and its implementation constitutes another semiotic register in Duval's sense, alongside textual Logo.
These inspirations are transformed into the line-based Logo design proposed here. The colours are not yet decided; they merely demonstrate their intended purpose of highlighting semantic relationships.
It may be worthwhile to consider icons as symbols for procedures where possible. However, the
written names (adapted to the user's chosen language) are not intended to be suppressed
completely. The display of names or icons should remain a deliberate choice. Here, the names of
the frames TO, MAKE, SUM, and THING are displayed in textual form. These
names shall be typeset in small caps. The chosen name for the procedure defined within the TO
frame (here: INCREMENT) is likewise typeset in small caps, as is the variable name VARIABLE.
As another representation of the same underlying definition, textual input can be displayed in visual
syntactic form, and vice versa.
The visual frame is not an execution frame; however, the correspondence becomes suggestive when recursive evaluation exposes nested execution frames.
The differences between a command and an operation become immediately apparent: a command
encloses operations, which are in turn linked together in a linear plug-in system of connectors.
A command has no external connector. If commands take other commands as input—such as TO
taking MAKE—the input quasi "slides into" the outer command. A command pushed into another
is also recognisable by protruding from it.
The custom inputs defined in the TO frame can be selected interactively, for example through
a right-click action. As with bindings in a custom procedure in Scratch, these inputs of a
definition with TO can be dragged and dropped onto an item that takes a variable name.
The idea of adopting the shorthand :variable through a corresponding shorthand item,
may survive the planning stage. It is equivalent to THING "variable. During visual-syntactic
programming, it could be possible to drag and drop the THING frame together with the
QUOTE item (shown here in green), into which a word can be entered or a variable dropped.
This combination would then conflate into the shorthand item (shown here in purple). The QUOTE
items are always atoms (= words), and never frames. Hence, the shorthand item representing THING "
appears as an atom, while concealing the frame structure of the compound expression it represents.
The following three drawings show a continuing story of that procedure definition.
The next drawing demonstrates the line-oriented nature of this register in the input list of
the REPEAT frame. This form of visualisation requires items to grow dynamically according to
their input. A complex procedure definition with TO will likewise stack complete Logo
instructions.
A frame like TO always expects complete Logo instructions as inputs thus it remains straight.
Unquoted names that are not procedure names are interpreted as variable names. Explicit variable items are provided
for using them in the visual-syntactic register (shown here in blue). Similar to the shorthand representation of
thing ", these items only appear atomic, but they represent another value instead.
Logo is generous with combinations. The former definition of DOUBLE using the OUTPUT
frame is correct. However, the following alternative can also be defined without producing an
immediate error message.
Once called, for instance with 5, however, Logo will gently point out:
You don't say what to do with 10 in double2
The visual-syntactic form of TO indicates this problem by not adapting visually to the input.
By contrast, the last drawing shows how a list frame adapts to data instead of instructions.
The left side of the frames retains sufficient space for meta-information, such as the default number of inputs.
cLogos will provide two alternative turtle shapes, called "Elmer" and "Elsie" in memory of Gray Walter's cybernetic tortoises: "ELectro MEchanical Robots, Light Sensitive, with Internal and External stability" (Gray Walter 1950, p. 43; Papert/Solomon 1971, p. 3).
The first triangular shape is adopted from the Video demonstration of the historical A.I. Lab LISP LOGO (LLOGO) implementation. A triangle is both a basic geometric form and an arrow. The dot at its tip makes the turtle's heading immediately perceptible while simultaneously marking its head.
The additional dot indicating the current pen state is likewise taken from the LLOGO demonstration. Its position near the rear of the screen turtle—or light turtle in Papert's later terminology (Papert 1980, pp. 12, 56)—could be altered, however. The floor turtle used in the A.I. Lab—that is, the physical robot controlled by the Logo environment—originally carried a mechanism for raising and lowering a pen at its center (Papert/Solomon 1971, p. 4). The original Matatalab bot likewise provides a hole at its center through which a pen can simply be inserted for drawing. The position of the pen-state indicator may therefore be made configurable to accommodate concrete isomorphic floor turtles used with cLogos. An argument for placing the pen, and hence its indicator, at the rear of the turtle is geometric correspondence: after 50 turtle steps, the turtle's reference point reaches the endpoint of its trace, while a centrally positioned pen causes the turtle itself to occupy part of the line it has just drawn.
The second circular shape is an idealised turtle.
The idealised turtle deliberately retains a minimum of visual commitment. The circle is itself also a basic geometric form, and can therefore be continued consistently by the filled circles used as indicators for the turtle's head, legs, and pen. In this form, the turtle is less a depiction of an animal than a spatial instrument: its shape provides an orientation and a point of interaction without prescribing a particular creature.
More concrete representations have nevertheless been used in Logo-related educational environments. Turtle Math, for example, employed a more figurative turtle.
So does Logo Blocks.
cLogos will deliberately leave the light turtle visually underdetermined. Its unfilled geometric form does not prescribe what the turtle represents; rather, the empty space it leaves available can be occupied by something else. Therefore, rather than concretising the conceptual spatial tool itself, cLogos will separate the spatial and representational functions by adopting a Scratch-like notion of selectable costumes—following Atari Logo in spirit. A costume can then be understood as a visual representation that is virtually “plugged onto” the underlying turtle shape.
This distinction allows the turtle to remain conceptually stable while its appearance may change. The turtle's geometrical form belongs to the spatial model; the costume belongs to its visual representation. Consequently, changing the turtle's appearance does not entail changing the spatial object that moves, turns, draws, and serves as the reference for turtle geometry.
In this sense, the costume constitutes a further representational layer rather than another kind of turtle. The learner may therefore encounter the same computational and geometrical object under different visual guises without the underlying spatial relation having to be re-established.
The Turtle Tailor Shop will extend the tradition of Atari Logo's Turtle Shape Editor (Atari Logo Reference Manual, pp. 48-49; Atari Logo Introduction Manual, pp. 118-120) by providing four optional modes for creating costumes:
- Rectangular editor. The first mode will follow the original two-dimensional, rectangular Turtle Shape Editor.
- Matrix editor. The second mode will provide a scalable two-dimensional matrix ranging from 3×3 to 16×16 fields.
- Voxel editor. The third mode will extend the matrix principle into three dimensions, providing a scalable three-dimensional array of 3×3×3 to 16×16×16 fields.
- Drawing tool. The fourth mode will provide a conventional drawing interface for creating less geometrically constrained costumes.
In all four modes, the costume will be anchored to the underlying turtle at its centre. Its extent will determine the turtle's effective visual size and, where collision detection is enabled, its collision envelope. Thus, the costume does not merely decorate the turtle: it may also provide a representation of the spatial extent with which the turtle interacts with its environment.
The Turtle Tailor Shop thereby treats appearance itself as something that can be constructed, transformed, and substituted—by hand and through programming, without altering the underlying turtle as a computational and geometrical object.
From Turtle Math, the following tools will inspire the development of the cLogos Turtle user interface to support the two design principles (Clements 1996, pp. 10-12):
- Principle 1. Encourage building mathematics from visual and inuitive knowledge.
- Principle 2. Maintain close ties between representations.
The Turn rays, and the Turtle Turner are visual aids to translate spatial intuition from enactive actions to the screen by suggesting instructions, also supporting the discovery of "The Total Turtle Trip Theorem" (Papert 1980, p. 76).
Manually placing the turtle on its screen aids to find the corresponding Logo straight movement instruction.
Also manually manipulating drawn geometrical shapes yields corresponding instructions.
A toolbar gives point and click access to the implemented Turtle Tools.
Berkeley Logo provides a simplified user interface to the Logo environment. It starts in a wxWidgets
window in textscreen mode, i.e., without displaying the turtle space.
The turtle is shown in splitscreen mode. Thus, to arrange Berkeley Logo in the classic layout, the command
splitscreen toggles this mode on while the command textscreen toggles it off again.
The splitscreen mode is also implicitly toggled on once Turtle Talk begins, when the Logo REPL is still in textscreen mode.
The command setcursor, in turn, leaves the turtle screen untouched and manipulates the cursor position within textscreen mode. (Notice: Berkeley Logo does not support non-US keyboards, thus it can only
be properly used with a US keyboard layout.)
Other Logo environments offer more static graphical user interfaces, while following the same general idea of integrating the different aspects of Logo on a single surface. Terrapin's Block Logo, for instance, provides a Scratch-like look and feel as a web-browser application:
FMSLogo, as a traditional desktop application, favours an overviewable user interface in which the turtle dominates the screen. Textual input is reduced to a single prompt line below an instruction-history window, while control buttons allow the user to manipulate the execution flow through mouse clicks.
Turtle Math,in turn, offered a highly integrated GUI with numerous mutually supporting tools:
For several reasons, cLogos will visually separate input from output while integrating the corresponding components internally. The following animated GIF uses pencil sketches to simulate a possible cLogos look and feel.
As in Berkeley Logo, Turtle Talk implicitly invokes the turtle screen when it is not already open. In cLogos, however,
the command turtlescreen, rather than splitscreen, explicitly activates the turtle space. If the turtle screen
is already active, another call to turtlescreen toggles it off.
The command splitscreen, in turn, will be reinterpreted. Similar to Emacs,
explicitly splitting the screen concerns the Logo REPL alone. The REPL window is split horizontally, with both parts
displaying the same content.
The command vedi (spoken: "veddy") invokes the visual editor window for visual-syntactic programming. It
is related to tedi (spoken: "teddy"), which is displayed within the split REPL. tedi is the textual editor and
contains the textual representation of the visual content displayed by vedi; conversely, vedi displays the content of tedi
in visual syntactic form.
If the Logo REPL is not already split, invoking tedi implicitly splits it. The same applies to setcursor.
All of these commands toggle their respective components on and off in cLogos. To close tedi, for instance, its command is simply
entered again; the REPL then returns to being displayed in a single window.
The Charter's mission statement clearly defines:
cLogos:
- treats textual Logo as a first-class medium for rigorous symbolic reasoning,
- treats turtle geometry as one concrete, spatial embodiment of those same ideas,
- and treats visual-syntactic forms as alternative representations of a shared underlying semantics.
Text, motion, and symbol are not stages to outgrow; they are parallel ways of thinking.
These registers therefore need to interact and to remain equally available. They do not, however, need to remain simultaneously present throughout an exploration. When the focus is on symbolic reasoning within the textual register, the visual-syntactic register may fade into the background until it is needed. Conversely, while a problem is being explored through the visual-syntactic register, the textual register may remain in the background. The spatial embodiment of an idea is needed only when that idea is to be examined in geometric form.
Physically separating the media of the different registers does not prevent seamless shifts from one to another. Rather, it makes such shifts explicit. This also reflects the different technical frameworks underlying the registers:
- the textual register will be implemented with Ncurses, respectively PDcurses on Windows, using cl-charms,
- the visual-syntactic register may be implemented as a GTK application with cl-gtk4,
- turtle geometry will be made available through a custom CFFI bridge to Raylib.
The two editors—tedi and vedi—are siblings that provide different representations of a shared intermediate structure: the normalized syntactic form (NSF) of the Logo program. tedi presents and edits textual Logo, which can be passed through the Logo reader to produce this internal representation. vedi, in turn, renders the same representation as a visual-syntactic form. Conversely, changes made through vedi can be transformed back into Logo source text for display and further editing in tedi. Neither editor therefore constitutes the privileged source of truth; the normalized syntactic representation mediates between the two.
Their use is, however, on demand, rather than forced. In particular, maintaining a continuously active visual-syntactic representation may require more resources than the textual register. As long as vedi is not needed, keeping it open would therefore create unnecessary overhead, both visually and computationally. Although contemporary hardware may make the computational overhead negligible in a well-engineered implementation, maintaining continuously synchronised representations also creates opportunities for unnecessary processing, particularly where implementation compromises or temporary kludges accumulate.
Furthermore, input and output purposes deserve separate places. Conflating them, as illustrated by setcursor in Berkeley Logo, has interesting effects. Pragmatically, however, using the display as an output surface serves different purposes from using the REPL as the line-based listener of the programming environment—or “Command Center,” as Turtle Math puts it. Through splitscreen , these demands can breathe in different places within the textual register.
Likewise, the inspiration taken from Turtle Math to implement tools that suggest Logo instructions from mouse actions on the turtlescreen will target an output place—tedi in this case—rather than the REPL. The resulting instruction can then be inspected, modified, or executed through the textual register without turning the REPL itself into the direct target of the graphical interaction.