DOCTOR, the ELIZA-style conversational program on MIT CADR and LM-3

Evidence boundary

The evidence has three different dates and must not be collapsed into one release:

• Joseph Weizenbaum's 1966 ELIZA paper establishes the earlier engine/script architecture and the historical DOCTOR script context. It does not specify this Lisp Machine implementation.
• The public System 46 snapshot contains LMDOC; DOCTOR 5, inventoried as 14 February 1977. It preserves an older engine but not the corresponding rule script in this snapshot.
• The LM-3 System 303 Fossil tree is a maintained restoration branch. Its system-303 check-in preserves a later engine and DOCSCR together; the restoration check-in date is not the historical creation date of the code.

The exact artifacts inspected were:

The System 46 repository is pinned at Git commit 8e978d7d1704096a63edd4386a3b8326a2e584af. The LM-3 source is pinned at Fossil check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91, tagged system-303.

The two 7,088-byte historical files are not byte-identical. The System 46 artifact has four non-ASCII bytes near the final reminder to load the script; the LM-3 copy replaces those bytes so the phrase reads you expect. This is a local byte comparison, not evidence that the repaired copy was the exact file run in 1977.

A bounded search of the System 46 manual tree and the LM-3 documentation tree found no dedicated DOCTOR user manual. doctor.text.5 is Lisp source despite its location and extension, not an operator guide. The controls and detailed behavior below consequently come from code and the runtime probe, while the Weizenbaum paper supplies historical context only.

Lineage

Weizenbaum described ELIZA as a language-analysis framework whose behavior was largely determined by a replaceable script. The best-known script adopted a Rogerian conversational pose and was called DOCTOR. The CADR program preserves that division unusually plainly: doctor.lisp implements matching and reassembly, while docscr.lisp consists almost entirely of declarations that populate the engine's properties.

The maintained source headers identify the immediate inputs more narrowly:

• the engine came from a Multics pathname ending in doctor::doctor.lisp;
• the script came from a Multics pathname ending in doctor::doctor.script;
• comments credit DLW with removing obarray/readtable machinery, improving input, and later removing script readtable hacks;
• the source path contains the initials bsg, and the script comment calls some removed code “BSG hacks.”

Neither inspected source expands DLW or BSG, so this page does not guess at the names. The headers establish a Multics-to-Lisp-Machine source path, but not byte identity with Weizenbaum's original implementation or sole authorship of the intervening versions. The script header dates its readtable cleanup to 18 December 1980; that internal historical note must likewise be distinguished from the later Fossil restoration check-in date.

The System 46 artifact uses older storage, character, readtable, and evaluator idioms. The maintained LM-3 sequence .9 through .14 then records several restoration changes: constants for break characters, replacement of an undefined QUIT call, Zetalisp readtable/package modernization, removal of a temporary debug print, and final syntax cleanup. These revisions preserve the algorithm while changing some observable edge behavior.

Program boundary and entry

The System 303 system declaration places both files in package HACKS, under the logical pathname default SYS:DEMO;. Its MAIN module loads DOCTOR before DOCSCR. This order matters: the engine can be defined without a useful script, but the script is just property installation and does not provide a second top level.

Once the HACKS system or the two files are loaded, the callable entry is:

(HACKS:DOCTOR)

There is no DEFDEMO registration for DOCTOR in the pinned tree, no Dynamic Windows frame, no System Menu entry, no Select key, no command table, and no mouse command. It runs synchronously in the invoking stream, normally a Lisp Listener, prints the one-time prompt Tell me about your problem., and then repeatedly reads and answers lines.

This absence of a window wrapper is a user-interface fact, not evidence that the program is incomplete. It is one of the callable programs collected by the large HACKS system rather than one of its registered visual demonstrations.

How the engine works

The maintained execution path can be summarized as:

input line
  -> uppercase, split, intern, and translate words
  -> build a keyword stack from PRIORITY properties
  -> try keyword RULES and decomposition patterns
  -> rotate to a reassembly or redirect to another rule set
  -> substitute captured spans, print, and optionally remember
  -> alternate stored memory with a generic fallback when no keyword wins

What DOCSCR represents

DOCSCR is not serialized data, a database image, or a compiled snapshot. It is an executable Lisp source file containing 185 top-level DEFPROP forms plus one comment form. Loading it mutates properties of interned HACKS symbols.

An inert, non-evaluating parse of the exact 18,705-byte file produced this inventory. The parser honored parentheses, semicolon comments, slash-escaped characters, and the file's case-folded symbol semantics before classifying the four arguments of each DEFPROP form.

The 42 full rule sets contain 93 decomposition patterns and 313 response alternatives. Their patterns use 147 variable-length zero captures and six exact-one captures; the three memory patterns add five and one respectively. The memory rules have 11 response alternatives. Source-level control responses are also countable: 25 NEWKEY redirects, 14 HOW redirects, six PRE forms, one EVAL form, and smaller redirect families for DREAM, YOU, DIT, XXYYZZ, WHAT, WAS, and COMPUTER. The matcher invokes BELIEF twice and FAMILY once.

These are declaration-corpus counts, not a claim that every declaration survives as a distinct live property. A later DEFPROP for the same symbol and property replaces the earlier value; the case-folding question around the two Multics spellings is the material example in this file.

The subject matter spans apologies, recollection, dreams, uncertainty, machines, family, self-description, comparisons, causation, quantifiers, and several joke or site-specific additions. A vocabulary list should not be read as an ontology. Most symbols merely lead to hand-written conversational templates, and many aliases share the same list.

Complete user-visible controls

DOCTOR defines no application keymap. Its complete application-owned control surface consists of its Lisp entry point, ordinary submitted lines, and one script token. Everything else is inherited from the invoking stream or the global window system.

While the maintained program waits in READLINE, the complete System 303 rubout-handler bindings remain available: numeric arguments; character, word, line, and Lisp-form movement; mark and region operations; deletion, transposition, quoting, redisplay, input and kill histories, completion, and context help. They are enumerated, including every key, in the Lisp Listener's input-editor tables. Duplicating those bindings as “Doctor commands” would give the wrong ownership and imply an application keymap that does not exist.

Workflows and observable behavior

Security, persistence, and side effects

This program predates modern isolation expectations.

• Every input word is interned in package HACKS. Arbitrarily varied input can grow the package and world even when no response remembers the text.
• Loading DOCSCR installs properties on many symbols. Response rotation then mutates those rule lists, and the memory path appends reconstructed material to a global fallback list.
• The one EVAL response is trusted script code. In the inspected script it prints a fixed phrase and calls (BREAK DOCTOR); it does not evaluate the user's line as Lisp. A modified script can execute arbitrary Lisp with the process's authority.
• The engine supplies no privacy, authentication, medical safeguards, or data classification. The surrounding Listener may retain submitted input in its history, and a later world save could persist interned symbols and mutated rule state.
• The engine itself performs no network access and writes no files. Its normal SYS: source-loading path can nevertheless involve a network file host.

No raster font, vector font, icon, picture, sound, or other standalone asset is embedded in either source file. The only visible output is text rendered by the invoking stream's existing fonts.

Source-visible discrepancies and defects

Several details would be missed by reading only a general ELIZA description:

1. The exit token regressed. DOCSCR maps 10-4 to ZAP. The 1977 engine handles ZAP by calling QUIT. In maintained revision .11, that call was replaced by (RETURN-FROM ANALYZE T). The outer DOCTOR loop immediately reads another line. The live .14 probe confirmed the static prediction: 10-4 produced no answer and did not return the original Listener to Lisp evaluation. Two following Lisp-looking lines were echoed but not evaluated; a second Listener was required for the next test.
2. The saved warning is stale. cwarns-hacks.lisp.1 reports obsolete EXPLODEC and MAKNAM calls and an undefined HACKS::QUIT. The first two still apply to .14; the QUIT warning can only describe a pre-.11 compile or a warning record carried forward without regeneration, because .14 has no such call.
3. A debug print briefly escaped. Revision .12 wrapped the exploded input list in PRINT, which would expose tokenizer state on every line. Revision .13 removes it; .14 retains the quiet path.
4. The Multics rules may collide under case folding. The script installs both Multics and multics forms, then places a full rule list and a one-symbol alias on those spellings. The inert case-folded audit treats them as one symbol, in which case the final alias can replace the full rule and redirect to itself. Exact live reader/package behavior and the resulting response path remain a runtime open question.
5. The source says input improvement was unfinished. The maintained header labels its READIN improvement “in progress,” consistent with the retained obsolete character-to-symbol pipeline and the unrestricted interning side effect.

These findings attach to the pinned files. They do not establish what a different historical load band, package case mode, or locally patched script did.

Runtime probes: System 303-0

(fboundp 'hacks:doctor)
(load "SYS:DEMO;DOCTOR")

(load (fs:make-pathname
        :host "LOCAL-BRIDGE"
        :raw-directory '("tree" "demo")
        :raw-name "doctor"
        :raw-type "lisp"))

(load (fs:make-pathname
        :host "LOCAL-BRIDGE"
        :raw-directory '("tree" "demo")
        :raw-name "docscr"
        :raw-type "lisp"))

Open questions

• How does live response rotation compare across a freshly reloaded script, and when does the memory fallback become visible in a controlled transcript?
• Does the scripted YOU WANT ... LISP response enter the same break loop in this load band that static inspection predicts?
• Does the live System 303 reader collapse Multics and multics in this file, and if so, does the final alias make that keyword path self-referential?
• Which people are identified by the source initials DLW and BSG, and who performed the original Multics-to-Lisp-Machine port?
• Where is the exact rule script paired with the inventoried 1977 System 46 engine, and did it differ from docscr.lisp.6 beyond readtable cleanup and later local jokes?
• Which physical Lisp Machine keys generated the old private reader's numeric codes? Source-visible effects are known, but the keyboard mapping is not.
• Was doctor.lisp.14 ever rebuilt into a surviving HACKS load artifact after the stale QUIT warning, or is the source ahead of the available compiled state?

Reproducibility and sources

The artifact sizes and hashes above can be reproduced with wc -c and sha256sum. The structural inventory was made without loading DOCSCR: tokenize the exact file while honoring semicolon comments and slash escapes, parse only balanced lists, select four-element forms headed by DEFPROP, case-fold symbol tokens, and classify the fourth element. Pattern and response totals then walk only full RULES and MEMR property values; one-symbol RULES values are aliases. This method deliberately performs no EVAL, interning, or property mutation.

• Joseph Weizenbaum, “ELIZA—A Computer Program For the Study of Natural Language Communication Between Man and Machine”, Communications of the ACM 9(1), 1966, pp. 36–45.
• Public System 46 snapshot, LMDOC; DOCTOR 5 and its media-inventory record, Git commit 8e978d7d1704096a63edd4386a3b8326a2e584af.
• LM-3 System 303, DEMO; DOCTOR LISP 14, DEMO; DOCSCR LISP 6, and the HACKS system declaration, Fossil check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91.
• LM-3 restoration HACKS compiler-warning record, used only as evidence about the saved build and its stale warning.

Last verified: 2026-07-18.