This page is a draft and will remain in a rough state for a while. (started: 25 June 2026)

Insight 1: Logo has three orthogonal composition systems

• procedural (prefix)
• structural (delimiters)
• relational (infix)

These systems are independent but coexist in a single Logo instruction.

They must be resolved during parsing:

Procedural:

print sum 1 2

Structural:

show (map "sum [1 2] [30 40] [500 600])

Relational:

print sum 1 2 + difference 4 3 * quotient 5 6

Here, prefix procedures and infix operators coexist in a single linear sentence.

Insight 2: Logo and Lisp are different

Both are symbolic, but in a sense with reversed pedagogical direction.

• In Logo, meaning flows from action (command) to structure.
• In Lisp, meaning flows from structure (form) to effect.

---

Logo's syntax

In principle (special cases excluded):

A typical Logo line starts with a command that ideally is named as a verb. And this verb sets the stage for the nouns, which are operations producing values.

This clearly separates concerns among the two kinds of Logo procedures:

• Commands have an effect, like showing a value.
• Operations produce output values from their input values.

Actually, there could be a third kind "emitters" for nullary procedures, i.e. procedures that take no arguments but output a value anyway, without operating on input values (e.g. pos that outputs the turtle's current position). Such procedures can only stand at the end of a Logo line, because otherwise they would interrupt the accumulation.

An expression is a complete operation call that outputs a value:

sum 2 3

An expression is also an atom that evaluates to itself, fundamentally a word:

"foo

In Logo, numbers are words too:

5

A Logo line is a complete instruction if a command (verb) precedes the expressions consisting of operations (nouns) and their arguments (maybe: particles). Thus Logo instructions form imperative sentences, e.g.

print sum 2 3

This makes each Logo instruction appear as strictly functional in style -- a composition of procedures of which the operations conclude in the effecting command.

But Logo instructions are also sentences which are read in European conventional reading-direction from left to right.

The syntax of these sentences is positional: A word in a sentence is either a procedure -- or it is a datum that follows a procedure as its input according to the procedure's arity.

These sentences are further structured through delimiters as punctuation marks.

• Parentheses associate parts of a sentence as groups, temporarily suspending a procedure’s default arity.

  print (sum 2 3 4)
  

• Square brackets associate list elements.

  print [this is a list]
  

• Curly braces associate array elements.

  print {this is an array}
  

• Infix operators encode a tree-structure in the linear instruction through precedence and associativity.

  print sum 1 2 + difference 4 3 * quotient 5 6
  

  implies this linear structure (directly accepted by Berkeley Logo):

  print sum sum 1 2 product difference 4 3 quotient 5 6
  

  And:

  print 4 - 3 - 2
  

  implies

  print difference (difference 4 3) 2
  

  if left associativity is applied. (Note: cLogos allows controlled precedence and associativity experiments.)

Note:

Logo’s syntax reflects the linguistic insight from valency theory (Tesnière) and case grammar (Fillmore): verbs define actions and determine the number and roles of their participants. Logo procedures act as verbs that set the stage as "little dramas" (Tesnière) or "scenarios" (Àgil) for their inputs, which fill semantic roles within an instruction.

Lisp's syntax

In Lisp, symbolic expressions (S-expressions), or forms synonymously, are the core abstraction that determines the syntax.

A Lisp form is either an Atom:

• Symbol: 'foo
• Number: 3/2

Or a Lisp form is at least one cons cell (an ordered pair of pointers) that are combined as links to form singly-linked lists of arbitrary complexity which are especially suitable as linear representation of a tree structure:

(print (+ (+ 1 2) 
          (* (- 4 3)
             (/ 5 6))))

Such list representation can either be used in evaluation mode, as above. Or they are used in data mode through quoting as below:

'(print (+ (+ 1 2) 
           (* (- 4 3)
              (/ 5 6))))

The quoted list returns itself in data mode:

(print (+ (+ 1 2) 
          (* (- 4 3)
             (/ 5 6))))

Because any list is a S-expression, any list returns at least one value (if not explicitly suppressed). And these values don't need to be channeled through an action. So, this is already sufficient to yield a value:

(+ (+ 1 2) 
   (* (- 4 3)
      (/ 5 6))))

In evaluation mode, this form returns 23/6 while, as input to print the value is shown on the screen and it is returned.

This determines a syntactical structure in Lisp, where parentheses delimit expressions and make the relations of combined processes explicitly visible through their tree structure.

Note:

The evaluation model of Lisp is based on algebraic conceptions (Kleene: recursion theorem, Church: lambda calculus).

Conclusion

• Logo's evaluation model is natural-language oriented facing linear imperative sentences that symbolically express well-defined actions.
• Lisp's evaluation model is algebra oriented (recursion theorem, lambda calculus) facing relations explicitly defined in trees.

Insight 3: "Turtle Talk" is a (small) subset of Logo

Papert introduced Logo to a larger audience in his influential book Mindstorms with a strong emphasis on TURTLE TALK (Papert 1980, p. 56). This follows necessarily from his approach to use the Turtle as primary object-to-think-with in learning environments targeting children. See his third note from Mindstorm's introduction:

The history of the Turtle in the LOGO project is as follows. In 1968-1969, the first class of twelve "average" seventh-grade students at the Muzzy Junior High School in Lexington, Massachusetts, worked with LOGO through the whole school year in place of their normal mathematics curriculum. At that time the LOGO system had no graphics. The students wrote programs that could translate English to "Pig Latin," programs that could play games of strategy, and programs to generate concrete poetry. This was the first confirmation that LOGO was a learnable language for computer "novices." However, I wanted to see the demonstration extended to fifth graders, third graders, and ultimately to preschool children. It seemed obvious that even if the LOGO language was learnable at these ages, the programming topics would not be. I proposed the Turtle as a programming domain that could be interesting to people at all ages. This expectation has subsequently been borne out by experience, and the Turtle as a learning device has been widely adopted. Pioneer work in using the Turtle to teach very young children was done by Radia Perlman who demonstrated, while she was a student at MIT, that four-year-old children could learn to control mechanical Turtles. Cynthia Solomon used screen Turtles in the first demonstration that first graders could learn to program. At the other end of the age spectrum, it is encouraging to see that Turtle programming is being used at a college level to teach PASCAL. See Kenneth L. Bowles, Problem Solving Using PASCAL (New York: Springer-Verlag, 1977). Controlling Turtles has proven to be an engaging activity for retarded children, for autistic children, and for children with a variety of "learning disorders." See for example, Paul Goldenberg, Special Technology for Special Children (Baltimore: University Park Press, 1979). Turtles have been incorporated into the SMALLTALK computer system at the Xerox Palo Alto Research Center. See Alan Kay and Adele Goldberg, "Personal Dynamic Media" (Palo Alto, Calif.: Xerox, Palo Alto Research Center, 1976).

However, Papert's pedagogical success with Turtle Graphics gradually eclipsed the broader language that made this success possible. For many later authors, Logo became synonymous with the turtle environment through which they first encountered it. A common misconception is repeated by the inventor of the Hedy teaching programming language:

mini or toy languages specifically aimed at teaching, such as Scratch [ 47] or LOGO [42 ], ...

Mini-languages: Mini-languages are languages that are small and especially designed to support learning to program. A well-known example of a mini-language is Papert’s LOGO [ 42]. More modern examples of mini-languages are Scratch [ 47] and Karel the Robot [ 10 ]. Mini-languages are said to "provide a solid foundation for learning a general purpose language" [ 13 ], but learning a mini-language can also be a goal in itself, leading to the acquisition of algorithmic thinking.

Sub-languages: In the sub-language approach, programming is taught to novices using only a set of commands from a bigger programming language, which typically is one that is used in practice such as Pascal or later, Java. Initially the idea of sub-languages was not to have them successively grow, but to simply select a subset to teach. Examples are Helium, a subset of Haskell for educational purposes [ 26 ], and MiniJava [48] and ProfessorJ [25] for Java.

(Hermans 2020, pp. 259-260)

Logo is neither a mini-language, nor is Turtle Talk a sub-language. Papert's second note from Mindstorm's introduction already classifies it correctly:

LOGO is the name of a philosophy of education in a growing family of computer languages that goes with it. Characteristic features of the LOGO family of languages include procedural definitions with local variables to permit recursion. Thus, in LOGO it is possible to define new commands and functions which then can be used exactly like primitive ones. LOGO is an interpretive language. This means that it can be used interactively. The modern LOGO systems have full list structure, that is to say, the language can operate on lists whose members can themselves be lists, lists of lists, and so forth. Some versions have elements of parallel processing and of message passing in order to facilitate graphics programming. An example of a powerful use of list structure is the representation of LOGO procedures themselves as lists of lists so that LOGO procedures can construct, modify, and run other LOGO procedures. Thus LOGO is not a "toy," a language only for children. The examples of simple uses of LOGO in this book do however illustrate some ways in which LOGO is special in that it is designed to provide very early and easy entry routes into programming for beginners with no prior mathematical knowledge. The subset of LOGO containing Turtle commands, the most used "entry route" for beginners, is referred to in this book as "TURTLE TALK" to take account of the fact that other computer languages, for example SMALLTALK and PASCAL, have implemented Turtles on their systems using commands originally developed in the LOGO language. The TURTLE TALK subset of LOGO is easily transportable to other languages.

It should be carefully remembered that LOGO is never conceived as a final product or offered as "the definitive language." Here I present it as a sample to show that something better is possible. Precisely because LOGO is not a toy, but a powerful computer language, it requires considerably larger memory than less powerful languages such as BASIC. This has meant that until recently LOGO was only to be implemented on relatively large computers. With the lowering cost of memory this situation is rapidly changing. As this book goes to press, prototypes of LOGO systems are running on a 48K Apple II system and on a TI 99/4 with extended memory. Readers who would like to be kept informed of the status of LOGO implementations can write to me at LOGO project, MIT Artificial Intelligence Laborary, 545 Technology Square, Cambridge, Mass. 02139. See S. Papert et al., LOGO: A Language For Learning (Morristown, N.J.: Creative Computing Press, forthcoming, Summer 1980).

In general:

Turtle Talk started as a subset of Logo without adopting a different syntax within Logo. As a caveat: this subset didn't follow exactly the Logo naming convention where actions (effecting procedures) are termed as verbs, and operations (outputting procedures) are termed as nouns. Instead actions—i.e. moving the turtle and drawing lines—are termed as directions (FORWARD, BACKWARD, LEFT, RIGHT, etc.). However, this alone doesn't make Turtle Talk a domain specific language of Logo, because the naming convention is not a syntactic property. (Anyway, cLogos might once add a Charter-respecting alternative layer to restore naming discipline.)

Since Turtle Talk constitutes the interface to the turtle graphics system which is accessible only at runtime, it is not a library defined with Logo primitives, but itself a subset of Logo's instruction set of primitives.

Insight 3.5: "Turtle talk" is a transferable conceptual interface

The TURTLE TALK subset of LOGO is easily transportable to other languages.

That means:

Turtle Talk is not defined by Logo's concrete syntax. It is defined by the conceptual semantics of embodied movement in a geometric world.

Exactly because

FORWARD 100

isn't important.

The important thing is

"Move an embodied agent through a geometric world."

That's why Turtle Talk could migrate into

• Smalltalk: turtle forward: 100.
• Pascal: Forward(100);
• (Common) Lisp: (logo:forward 100)
• Scratch: move 100 steps
• Python: t.forward(100)
• JavaScript forward(100);

without ceasing to be Turtle Talk. The semantics travelled, the syntax changed.

Although the surrounding programming paradigms differ radically—message passing, procedural programming, functional programming, object-oriented programming, or visual programming—the learner encounters essentially the same embodied action.

Turtle Talk therefore behaves less like a language feature than like a transferable conceptual interface.