GOO

GOO - the name is an acronym for Generic Object Orientator - is a dynamic, type-based, object-oriented programming language built by Jonathan Bachrach at the MIT AI Lab in the early 2000s. Its own documentation describes the ambition with unusual precision: GOO “attempts to be a simpler lisp-syntaxed Dylan, an object-oriented Scheme, and a lispified Cecil,” aiming to “offer the best of both scripting and delivery languages while at the same time incorporating an extreme back-to-basics philosophy.”

That is a very specific place to stand. Dylan had a rich object model and a serious compiler but a heavy syntax and a heavy toolchain. Scheme had beautiful minimalism and no object system worth the name. Cecil had the most interesting dispatch semantics of the three and almost no users. GOO tried to take the object model from the first, the syntax and size from the second, the dispatch ideas from the third, and end up with something you could start in a REPL and still ship.

A note on dating. GOO is sometimes listed with a first-appearance year in the early 1990s. The primary record does not support that. The project’s own source repository begins on 19 April 2001, under the earlier name Proto; the rename to GOO appears in commits dated 13-15 March 2002; and the first Debian upload follows in May 2002. This page uses 2002 as the year GOO appeared under that name, with 2001 as the start of the work.

History and Origins

The Dylan years

Bachrach spent 1994 to 1999 at Harlequin working on Dylan, and then a further year at Functional Objects, the spin-off that took the Dylan compiler commercial. Dylan is the essential prior context. It is a language with CLOS-derived generic functions and multiple dispatch, a sealing discipline that lets a compiler devirtualise calls it can prove are closed, and - after its early Lisp-syntax phase - an ALGOL-style infix surface syntax adopted to look less alien to mainstream programmers.

Two things about that experience shaped GOO. First, Bachrach had already worked out, with Keith Playford, how to keep Lisp-grade macro power in a language with conventional syntax - the 1999 “D-Expressions: Lisp Power, Dylan Style” report, and later the OOPSLA 2001 paper on the Java Syntactic Extender, which did the same trick for Java. Second, he had seen how much machinery a Dylan implementation required. GOO is in large part a reaction: keep the object model, drop the syntax, drop the weight.

Proto, 2001

The project starts on 19 April 2001 as Proto, bootstrapped from an emulator written in Dylan itself - the repository still contains that emulator as a set of .dylan files with an Open Dylan project descriptor. By 10 May 2001 the commit log records “proto v0.82 bootstrapped!”, meaning the language could compile itself and the Dylan scaffolding could be retired.

The Proto manual of 20 September 2001 is remarkably candid about the state of the implementation:

Proto is pretty slow at this point. I’m using an AST-based interpreter. This will improve in coming releases. There is not a large amount of debugging support. In particular, there is no backtrace facilities.

Bachrach presented the work that year at the first Lightweight Languages conference at MIT, in a talk that paired it with the Java Syntactic Extender under the heading “Rethinking Lightweight Languages.”

Becoming GOO, 2002

In March 2002 the project renames itself. The commit log tells the story in three lines - “goo first cut” on 13 March, “goo v114” on 14 March, “proto2goo” and “goo release script” on 15 March - and a proto2goo.txt file in the repository catalogues everything that was added, removed or renamed in the transition. Two months later, on 18 May 2002, Debian accepted the first goo package.

The name change also freed the word “Proto,” which Bachrach reused years later for an entirely different language - the spatial-computing language he developed with Jacob Beal for programming sensor networks and swarms. The two are unrelated apart from their author.

Design Philosophy

Type-based, not type-checked

The single most distinctive idea in GOO is captured in the phrase it uses about itself: it is a type-based language. Types are ordinary first-class runtime values. You can compute with them, pass them around, and construct new ones with combinators:

• (t+ a b) builds a union type
• (t< <class>) builds a subclass type - the type of classes descending from a given class
• (t= value) builds a singleton type matching exactly one value
• (t? x) is (t+ x (t= #f)) - the ubiquitous “x or false” optional type

Annotations are optional and are written with a vertical bar: x|<int>. They appear on parameters, on return values after a => marker, and on slots. They are not a static type system - GOO is dynamically checked - but they are not merely documentation either, because they are exactly what method dispatch uses.

Everything dispatches

There are no methods-in-classes. As in CLOS, Dylan and Cecil, GOO has generic functions with multiple dispatch: a generic is declared with dg, methods are added to it with dm, and the method chosen at a call site depends on the runtime types of all the arguments, not just the first. next-method walks the applicable chain.

Because dispatch is by type and types include unions and singletons, a great deal that other languages express with if chains is expressible as method specialisation instead.

Small vocabulary, terse names

GOO takes brevity to a degree that is initially startling. Definitions are two-letter forms - dc class, dm method, dg generic, df function, dv variable, dp property, ds macro. Special forms are three letters: fun, let, loc, lab, fin, seq, rep. Classes are conventionally bracketed, <int>, <str>, <col>.

The project’s own proposal files show this was contested. DEFINITIONS.TXT opens: “current definition special form names are unpronouncable as words. also the definition doesn’t look like the usage” - filed as an open issue against the language by its own author.

Key Features

Syntax by example

A fragment from the bank demo in the source tree shows most of the language at once:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

(use goo)

(dc <account> (<any>))
 (dp balance (<account> => <int>) 0)

(dc <checking-account> (<account>))
(dc <savings-account> (<account>))

(dv *minimum-balance* 100)

(dm credit (account|<account> amount|<int>)
  (opf (balance account) (+ _ amount))
  #t)

(dm can-handle-debit? (account|<account> amount|<int> => <log>)
  (>= (balance account) amount))

(dm transfer (from|<account> to|<account> amount|<int> => <log>)
  (when (and (> amount 0) (can-handle-debit? from amount))
    (debit from amount)
    (credit to amount)))

dc declares a class with its direct parents. dp declares a property with its type and default. dm adds a method, whose parameters carry |type specialisers and whose return type follows =>. <log> is the boolean class. opf is the operate-and-update macro; the _ is the placeholder for the current value, so (opf (balance account) (+ _ amount)) is the equivalent of balance += amount while going through the setter.

The core is genuinely small

The whole special-form vocabulary fits on a page: quote, if, seq, set, fun, let, loc, lab, fin, dv, dm, dg, dc, isa, slot, ds, ct, macro-expand, next-method, use, export. Everything else - df, and, or, when, select, case, rep, try, inc - is a macro over that core. The manual annotates each form with its ancestor: seq is Scheme’s begin, loc is letrec, lab is Dylan’s block/return, fin is Dylan’s block/cleanup and Common Lisp’s unwind-protect.

Macros

Macros are defined with ds and written as quasiquoted pattern-and-template pairs, in the destructuring style Bachrach had explored in Dylan and Java:

1
2

(ds (when ,test ,@body)
  `(if ,test (seq ,@body) #f))

ct evaluates its body at compile time so that macro expansion can depend on computed values, and macro-expand exposes the expander. The macros were unhygienic during the language’s active life - the changelog and bug list both carry the item “document that macros are unhygienic at present,” and hygiene appears on the to-do list rather than in the implementation.

Dynamic compilation to C

GOO ships two front ends: goo, which defaults to AST interpretation, and g2c, which defaults to translating expressions into C and compiling them dynamically. Either mode can be selected at runtime with the GOO_EVAL_MODE environment variable or with the ,g2c-eval and ,ast-eval REPL commands. This is the “Simple Dynamic Compilation” of the 2002 Harvard talk, and it is the project’s answer to the slowness Bachrach had flagged in the 2001 Proto manual: keep the interactive interpreter for development, generate C for delivery, without changing the source.

The optimisation notes in the repository list what the compiler actually did - self-recursive call detection, dynamic-extent analysis, a dispatch cache, stack allocation, inlined primitives - alongside a longer list of things that were still wanted. No published benchmark accompanies these, and the project never made a quantitative performance claim; the honest summary is that GOO aimed at delivery-grade performance and got far enough to run real-time MIDI code, not that it was measured against anything.

The runtime

The runtime is C, garbage-collected with the Boehm conservative collector, with threads and locks built on POSIX threads and a corresponding event layer. Bignum arithmetic arrived last, in 0.155, via GMP. The lightweight C embedding facility added in 0.154 lets C text be written directly inside GOO source through c-ment and c-expr forms and the #{} and #" "# reader syntaxes, so bindings could be written without a separate interface-definition step.

Modules are handled by use and export at file granularity. The project’s own proposal files debated richer designs - MODULES.TXT, SIMPLE-MODULES.TXT, DYNAMIC-OVERLOADING.TXT, PARAMTYPES.TXT - and most of them remained open when work stopped.

Evolution

The version history is dense and short. Roughly seventy-eight numbered releases are recorded in the changelog, running from the Proto 0.8x series in 2001 through the 0.1xx series that carried the GOO name. Development pace over 2002 is brisk: the roughly forty versions between 0.114 in March 2002 and 0.153 in January 2003 work out closer to a release a week than a release a fortnight.

After 0.155, upstream work stops. Bachrach’s 2004 Lightweight Languages talk on Gooze, a multimedia stream processing language, is the visible successor of the real-time-media thread that ran through GOO from the beginning, but GOO itself received no further releases.

Current Relevance

GOO is dormant, and has been for over two decades. There is no active mailing list traffic, no package ecosystem, and no user community. The source lives on GitHub under the googoogaga organisation - the name of the project’s old mailing list and domain - as an archive of the CVS-era history, GPL v2 licensed, its last commit dated 19 November 2003.

What is genuinely unusual is that it still runs. Debian has packaged goo continuously since May 2002, and and as of the May 2025 upload the package is present as 0.155+ds-6, with maintenance work as recent as that date fixing threading behaviour under GCC 15. For anyone wanting to try the language, installing the Debian package inside a container is far less work than building the 2003 source against a modern compiler. No official or community Docker image exists.

The documentation that survives is better than the language’s obscurity would suggest: a reference manual, an introduction, and lecture decks on the implementation and on the bootstrapping process, all still hosted on Bachrach’s MIT CSAIL pages.

Why It Matters

It is a careful subtraction from Dylan. Most language design proceeds by addition. GOO went the other way: take a design its author knew intimately from six years of professional work, identify what was essential - the generic-function object model, multiple dispatch, first-class types, macros - and discard the rest, including the infix syntax that had been Dylan’s most visible break with its Lisp ancestry. The result is one of the cleanest available demonstrations of what a CLOS-family object model looks like once everything else is stripped away.

It took first-class types seriously. The t+/t</t= combinators, and the t? optional type built out of them, give a dynamic language a compositional vocabulary for describing what a parameter accepts - unions, singletons, subclass-of - without a static type checker. Optional gradual annotations that participate in dispatch rather than merely in checking remain a comparatively rare design point.

Its two-mode execution model prefigured a now-standard idea. Interpret for interactivity, compile natively for delivery, switch between them with an environment variable, and keep one source language for both. That combination is now routine in dynamic language runtimes; in 2002, doing it by generating C and invoking the system compiler at runtime was a pragmatic and instructive way to get there on a research budget.

It is a complete, legible artefact. A small runtime, a self-hosted compiler, a bootstrap path documented in its own lecture notes, some seventy-eight changelogged releases, an open list of unresolved design proposals filed by the author against his own language, and a package that still builds. As a specimen for studying how a dynamic object-oriented language is actually built - rather than how a finished one is used - GOO is more useful than most languages a hundred times its size.

Sources

• GOO home page, MIT CSAIL - project page, downloads for 0.153/0.154/0.155, documentation index and the operators list
• googoogaga.github.io - the mirrored project site, including the “supersedes preproto” note and the Generic Object Orientator expansion
• googoogaga/goo on GitHub - the full source history: initial import 19 April 2001, the March 2002 rename commits, txt/changes.txt, txt/proto2goo.txt, txt/speed.txt, the proposals/ directory, the Dylan emulator, and GPL v2 terms
• GOO reference manual - the “simpler, more dynamic, lisp-syntaxed Dylan” framing and the GPL statement
• GOO reference manual v46 (PDF) - dated 19 November 2003
• Simple Dynamic Compilation with GOO (PDF) - the Harvard colloquium slides on the g2c approach
• Jonathan Bachrach, curriculum vitae - Harlequin 1994-1999, Functional Objects 1999-2000, and the LL1, Harvard, MIT, UCSD and LL4 talks
• goo(1) manual page - goo and g2c, GOO_EVAL_MODE, and the REPL comma commands
• Debian package tracker: goo - version history through 0.155+ds-6 in May 2025
• Debian changelog for goo - initial release 0.133-1 on 18 May 2002, and the GCC 15 threading fix
• Publications about Dylan, Open Dylan - the 1999 D-Expressions report by Bachrach and Playford