Abstract
========
-The Muddle programming language began existence in late 1970 as a
-successor to Lisp (Moon, 1974), a candidate vehicle for the Dynamic
-Modeling System, and a possible base for implementation of Planner
-(Hewitt, 1969). The original design goals included an interactive
-integrated environment for programming, debugging, loading, and
-editing: ease in learning and use; facilities for structured, modular,
-shared programs; extensibility of syntax, data types and operators:
-data-type checking for debugging and optional data-type declarations
-for compiled efficiency; associative storage, coroutining, and
-graphics. Along the way to reaching those goals, it developed flexible
-input/output (including the ARPA Network), and flexible interrupt and
-signal handling. It now serves as a base for software prototyping,
-research, development, education, and implementation of the majority
-of programs at MIT-DMS: a library of sharable modules, a coherent user
-interface, special research projects, autonomous daemons, etc.
+The Muddle programming language began existence in late 1970 (under
+the name Muddle) as a successor to Lisp (Moon, 1974), a candidate
+vehicle for the Dynamic Modeling System, and a possible base for
+implementation of Planner (Hewitt, 1969). The original design goals
+included an interactive integrated environment for programming,
+debugging, loading, and editing: ease in learning and use; facilities
+for structured, modular, shared programs; extensibility of syntax,
+data types and operators: data-type checking for debugging and
+optional data-type declarations for compiled efficiency; associative
+storage, coroutining, and graphics. Along the way to reaching those
+goals, it developed flexible input/output (including the ARPA
+Network), and flexible interrupt and signal handling. It now serves as
+a base for software prototyping, research, development, education, and
+implementation of the majority of programs at MIT-DMS: a library of
+sharable modules, a coherent user interface, special research
+projects, autonomous daemons, etc.
This document was originally intended to be a simple low-level
introduction to Muddle. It has, however, acquired a case of
misconceptions, I would like to thank Chris Reeve, Bruce Daniels, and
especially Gerald Sussman, one of whose good ideas I finally did use.
-*Greg Pfister\
-December 15, 1972*
+Greg Pfister\
+December 15, 1972
Since Greg left the fold, I have taken up the banner and updated his
document. The main sources for small revisions have been the on-line
("the oracle") for the patience to answer questions and resolve
doubts, as he no doubt as done innumerable times before.
-*S. W. Galley\
-May 23, 1979*
+S. W. Galley\
+May 23, 1979
This work was supported by the Advanced Research Projects Agency of
the Department of Defense and was monitored by the Office of Naval
are not covered in the text. Ignore examples as your peril.
This document does not assume knowledge of any specific programming
-language on the \[sic\] your part. However, "computational literacy"
-is assumed: you should have written at least one program before. Also
-very little familiarity is assumed with the interactive time-sharing
-operating systems under which Muddle runs -- ITS, Tenex, and Tops-20
--- namely just file and user naming conventions.
+language on your part. However, "computational literacy" is assumed:
+you should have written at least one program before. Also very little
+familiarity is assumed with the interactive time-sharing operating
+systems under which Muddle runs -- ITS, Tenex, and Tops-20 -- namely
+just file and user naming conventions.
### Notation
Most specifically indicated examples herein are composed of pairs of
lines. The first line of a pair, the input, always ends in `$` (which
-is how the ASCII character ESC is represented, and which always
+is how the ASCII character `ESC` is represented, and which always
represents it). The second line is the result of Muddle's groveling
over the first. If you were to type all the first lines at Muddle, it
would respond with all the second lines. (More exactly, the "first
An ellipsis (...) indicates that something uninteresting has been
omitted. The character `^` means that the following character is to be
-"controllified": it is usually typed by holding down a terminal's CTRL
-key and striking the other key.
+"controllified": it is usually typed by holding down a terminal's
+`CTRL` key and striking the other key.
Chapter 1. Basic Introduction
=============================
echoed (printed on your terminal) and remembered in a buffer. The only
characters for which this is normally not true act as follows:
-Typing `$` (ESC) causes Muddle to echo dollar-sign and causes the
+Typing `$` (`ESC`) causes Muddle to echo dollar-sign and causes the
contents of the buffer (the characters which you've typed) to be
interpreted as an expression(s) in Muddle. When this interpretation is
done, the result will be printed and Muddle will wait for more typing.
-ESC will be represented by the glyph `$` in this document.
-
-Typing the rubout character (DEL in the ITS and Top-20 versions,
-CTRL+A in the Tenex version) causes the last character in the buffer
--- the one most recently typed -- to be thrown away (deleted). If you
-now immediately type another rubout, once again the last character is
-deleted -- namely the second most recently typed. Etc. The character
-deleted is echoed, so you can see what you're doing. On some "display"
-terminals, rubout will "echo" by causing the deleted character to
-disappear. If no characters are in the buffer, rubout echoes as a
-carriage-return line-feed.
-
-Typing \^@ (CTRL+@) deletes everything you have typed since the last
-`$`, and prints a carriage-return line-feed.
-
-Typing \^D (CTRL+D) causes the current input buffer to be typed back
-out at you. This allows you to see what you really have, without the
-confusing re-echoed characters produced by rubout.
-
-Typing \^L (CTRL+L) produces the same effect as typing \^D, except
-that, if your terminal is a "display" terminal (for example, IMLAC,
-ARDS, Datapoint), it firsts clears the screen.
-
-Typing \^G (CTRL+G) causes Muddle to stop whatever it is doing and act
-as if an error had occurred ([section
-1.4](#14-errors-simple-considerations-1)). \^G is generally most
+`ESC` will be represented by the glyph `$` in this document.
+
+Typing the rubout character (`DEL` in the ITS and Top-20 versions,
+`CTRL`+`A` in the Tenex version) causes the last character in the
+buffer -- the one most recently typed -- to be thrown away (deleted).
+If you now immediately type another rubout, once again the last
+character is deleted -- namely the second most recently typed. Etc.
+The character deleted is echoed, so you can see what you're doing. On
+some "display" terminals, rubout will "echo" by causing the deleted
+character to disappear. If no characters are in the buffer, rubout
+echoes as a carriage-return line-feed.
+
+Typing `^@` (`CTRL`+`@`) deletes everything you have typed since the
+last `$`, and prints a carriage-return line-feed.
+
+Typing `^D` (`CTRL`+`D`) causes the current input buffer to be typed
+back out at you. This allows you to see what you really have, without
+the confusing re-echoed characters produced by rubout.
+
+Typing `^L` (`CTRL`+`L`) produces the same effect as typing `^D`,
+except that, if your terminal is a "display" terminal (for example,
+IMLAC, ARDS, Datapoint), it firsts clears the screen.
+
+Typing `^G` (`CTRL`+`G`) causes Muddle to stop whatever it is doing
+and act as if an error had occurred ([section
+1.4](#14-errors-simple-considerations-1)). `^G` is generally most
useful for temporary interruptions to check the progress of a
-computation. \^G is "reversible" -- that is, it does not destroy any
-of the "state" of the computation it interrupts. To "undo" a \^G, type
-the characters
+computation. `^G` is "reversible" -- that is, it does not destroy any
+of the "state" of the computation it interrupts. To "undo" a `^G`,
+type the characters
<ERRET T>$
(This is discussed more fully far below, in section 16.4.)
-Typing \^S (CTRL+S) causes Muddle to **throw away** what it is
+Typing `^S` (`CTRL`+`S`) causes Muddle to **throw away** what it is
currently doing and return a normal "listening" state. (In the Tenex
-and Tops-20 versions, \^O also should have the same effect.) \^S is
+and Tops-20 versions, `^O` also should have the same effect.) `^S` is
generally most useful for aborting infinite loops and similar terrible
-things. \^S **destroys** whatever is going on, and so it is **not**
+things. `^S` **destroys** whatever is going on, and so it is **not**
reversible.
Most expressions in Muddle include "brackets" (generically meant) that
must be correctly paired and nested. If you end your typing with the
-pair of characters `!$` (!+ESC), all currently unpaired brackets (but
-not double-quotes, which bracket strings of characters) will
-automatically be paired and interpretation will start. Without the !,
-Muddle will just sit there waiting for you to pair them. If you have
-improperly nested parentheses, brackets, etc., within the expression
-you typed, an error will occur, and Muddle will tell you what is
-wrong.
+pair of characters `!$` (`!`+`ESC`), all currently unpaired brackets
+(but not double-quotes, which bracket strings of characters) will
+automatically be paired and interpretation will start. Without the
+`!`, Muddle will just sit there waiting for you to pair them. If you
+have improperly nested parentheses, brackets, etc., within the
+expression you typed, an error will occur, and Muddle will tell you
+what is wrong.
Once the brackets are properly paired, Muddle will immediately echo
carriage-return and line-feed, and the next thing it prints will be
you have some expression unclosed. In that case, if you have not typed
any characters beyond the `$`, you can usually rub out the `$` and
other characters back to the beginning of the unclosed expression.
-Otherwise, what you have typed is beyond the help of rubout and \^@;
-if you want to abort it, use \^S.
+Otherwise, what you have typed is beyond the help of rubout and `^@`;
+if you want to abort it, use `^S`.
Muddle accepts and distinguishes between upper and lower case. All
"built-in functions" must be referenced in upper case.
met. Instead, the right-hand column will be used to state just what
`READ` thought the input in the left-hand column really was.
- --------------------------------------------------------------------------------
+ ------------------------------------------------------------------------------------
Input Explanation
- --------------------------- ----------------------------------------------------
+ --------------------------- --------------------------------------------------------
`ABC$` an `ATOM` of `PNAME` `ABC`
`abc$` an `ATOM` of `PNAME` `abc`
something else (The something else will contain an
`ATOM` of `PNAME` beginning `cd.`)
- `12345A34$` an `ATOM` of `PNAME` `12345A35` (If the A had been
- an E, the object would have been a `FLOAT`.)
- --------------------------------------------------------------------------------
+ `12345A34$` an `ATOM` of `PNAME` `12345A35` (If the A had been an E,
+ the object would have been a `FLOAT`.)
+ ------------------------------------------------------------------------------------
#### 2.6.3.3. (Backslash) in ATOMs
error, but because commenting is needed: `PRINT` doesn't do it full
justice.
- ---------------------------------------------------------------------------
+ -------------------------------------------------------------------------------
Input Explanation
- ------------------------ --------------------------------------------------
+ ------------------------ ------------------------------------------------------
`a\ one\ and\ a\ two$` one `ATOM`, whose `PNAME` has four spaces in it
- `1234\56789$` an `ATOM` of `PNAME` `123456789`, which `PRINT`s
- as `\1233456789`
+ `1234\56789$` an `ATOM` of `PNAME` `123456789`, which `PRINT`s as
+ `\1233456789`
`123\ $` an `ATOM` of `PNAME` `123space`, which `PRINT`s as
`\123\`, with a space on the end
`\\$` an `ATOM` whose `PNAME` is a single backslash
- ---------------------------------------------------------------------------
+ -------------------------------------------------------------------------------
Chapter 3. Built-in Functions
=============================
found in chapter 13.
Example: the following `FUNCTION` reads characters from the current
-input channel until an `$` (ESC) is read, and then returns what was
+input channel until an `$` (`ESC`) is read, and then returns what was
read as one `STRING`. (The `SUBR` `READCHR` reads one character from
the input channel and returns it. `NEXTCHR` returns the next
`CHARACTER` which `READCHR` will return -- chapter 11.)
### 11.1.1. Input
All of the following input Subroutines, when directed at a terminal,
-hang until `$` (ESC) is typed and allow normal use of rubout, \^D, \^L
-and \^@.
+hang until `$` (`ESC`) is typed and allow normal use of `rubout`,
+`^D`, `^L` and `^@`.
#### 11.1.1.1. READ
The following table tells which `SUBR`s can be used with which modes,
where `OK` indicates an allowed use:
- -------------------------------------------------------------------------------------------------------------------------------------------
- "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs
- -------------------- -------------------- -------------------- ------------------------------------------ ---------------------------------
- OK OK `READ` `READCHR` `NEXTCHR`
- `READSTRING` `FILECOPY`
- `FILE-LENGTH LOAD`
+ -------------------------------------------------------------------------------------------------------------------------------------------------
+ "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs
+ -------------------- --------------------- --------------------- -------------------------------------------- -----------------------------------
+ OK OK `READ` `READCHR` `NEXTCHR`
+ `READSTRING` `FILECOPY`
+ `FILE-LENGTH LOAD`
- OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE`
- `CRLF` `TERPRI` `FILECOPY`
- `PRINTSTRING` `BUFOUT` `NETS`
- `RENAME`
+ OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE`
+ `CRLF` `TERPRI` `FILECOPY`
+ `PRINTSTRING` `BUFOUT` `NETS`
+ `RENAME`
- OK `READB` `GC-READ`
+ OK `READB` `GC-READ`
- OK `PRINTB` `GC-DUMP`
+ OK `PRINTB` `GC-DUMP`
- OK OK OK `ACCESS`
+ OK OK OK `ACCESS`
- OK OK OK OK `RESET`
+ OK OK OK OK `RESET`
- OK OK `ECHOPAIR`
+ OK OK `ECHOPAIR`
- OK `TTYECHO` `TYI`
- -------------------------------------------------------------------------------------------------------------------------------------------
+ OK `TTYECHO` `TYI`
+ -------------------------------------------------------------------------------------------------------------------------------------------------
`*` PRINTing (or `PRIN1`ing) an `RSUBR` (chapter 19) on a `"PRINTB"`
or `"PRINTO"` `CHANNEL` has special effects.
*element-number: type interpretation*
- ------------------------------------------------------------------------------------------------
- element-number type interpretation
- ------------------------- ------------------ ---------------------------------------------------
- -1 `LIST` transcript channel(s) (see below)
+ ----------------------------------------------------------------------------------------------------
+ element-number type interpretation
+ -------------------------- ------------------ ------------------------------------------------------
+ -1 `LIST` transcript channel(s) (see below)
- \* 0 varies device-dependent information
+ \* 0 varies device-dependent information
- \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20),
- `0` for internal or closed
+ \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20), `0`
+ for internal or closed
- \* 2 `STRING` mode
+ \* 2 `STRING` mode
- \* 3 `STRING` first file name argument
+ \* 3 `STRING` first file name argument
- \* 4 `STRING` second file name argument
+ \* 4 `STRING` second file name argument
- \* 5 `STRING` device name argument
+ \* 5 `STRING` device name argument
- \* 6 `STRING` directory name argument
+ \* 6 `STRING` directory name argument
- \* 7 `STRING` real first file name
+ \* 7 `STRING` real first file name
- \* 8 `STRING` real second file name
+ \* 8 `STRING` real second file name
- \* 9 `STRING` real device name
+ \* 9 `STRING` real device name
- \* 10 `STRING` real directory name
+ \* 10 `STRING` real directory name
- \* 11 `FIX` various status bits
+ \* 11 `FIX` various status bits
- \* 12 `FIX` PDP-10 instruction used to do one I/O operation
+ \* 12 `FIX` PDP-10 instruction used to do one I/O operation
- 13 `FIX` number of characters per line of output
+ 13 `FIX` number of characters per line of output
- 14 `FIX` current character position on a line
+ 14 `FIX` current character position on a line
- 15 `FIX` number of lines per page
+ 15 `FIX` number of lines per page
- 16 `FIX` current line number on a page
+ 16 `FIX` current line number on a page
- 17 `FIX` access pointer for file-oriented devices
+ 17 `FIX` access pointer for file-oriented devices
- 18 `FIX` radix for `FIX` conversion
+ 18 `FIX` radix for `FIX` conversion
- 19 `FIX` sink for an internal `CHANNEL`
- ------------------------------------------------------------------------------------------------
+ 19 `FIX` sink for an internal `CHANNEL`
+ ----------------------------------------------------------------------------------------------------
N.B.: The elements of a `CHANNEL` below number 1 are usually invisible
but are obtainable via `<NTH <TOP channel> fix>`, for some appropriate
eventually returns `"DONE"`. First, however, it `READ`s and `EVAL`s
every Muddle object in the file pointed to by *input*, and then
-`CLOSE`s *input*. Any occurrences of rubout, ^@, ^D, \^L, etc., in the
-file are given no special meaning; they are simply `ATOM`
+`CLOSE`s *input*. Any occurrences of `rubout`, `^@`, `^D`, `^L`, etc.,
+in the file are given no special meaning; they are simply `ATOM`
constituents.
*look-up* is optional, used to specify a `LIST` of `OBLIST`s for the
<ECHOPAIR terminal-in:channel terminal-out:channel>
returns its first argument, after making the two `CHANNEL`s "know
-about each other" so that rubout, ^@, ^D and \^L on *terminal-in* will
-cause the appropriate output on *terminal-out*.
+about each other" so that `rubout`, `^@`, `^D` and `^L` on
+*terminal-in* will cause the appropriate output on *terminal-out*.
### 11.8.2. TTYECHO
<TYI terminal-input:channel>
returns one `CHARACTER` from *channel* (optional, `.INCHAN` by
-default) when it is typed, rather than after `$` (ESC) is typed, as is
-the case with `READCHR`. The following example echos input characters
-as their ASCII values, until a carriage-return is typed:
+default) when it is typed, rather than after `$` (`ESC`) is typed, as
+is the case with `READCHR`. The following example echos input
+characters as their ASCII values, until a carriage-return is typed:
<REPEAT ((FOO <TTYECHO .INCHAN <>>))
<AND <==? 13 <PRINC <ASCII <TYI .INCHAN>>>>
should use to do so. This is particularly true with respect to
locatives to `LVAL`s; the fact that they are independent of changes in
binding can save a lot of fooling around with `EVAL` and
-`ENVIRONMENT`s. \# Chapter 13. Association (Properties)
+`ENVIRONMENT`s.
+
+Chapter 13. Association (Properties)
+====================================
There is an "associative" data storage and retrieval system embedded
in Muddle which allows the construction of data structures with
inputs (what `READ` returns) in it, most recent first. Similarly, if
the `ATOM` `L-OUTS` has a local value that is a `LIST`, `LISTEN` will
keep recent outputs (what `EVAL` returns) in it, most recent first.
-The keeping is done before the `PRINT`ing, so that \^S does not defeat
-its purpose. The user can decide how much to keep around by setting
-the length of each `LIST`. Even if `L-OUTS` is not used, the atom
-`LAST-OUT` is always `SET` to the last object returned by `EVAL` in
-the standard `LISTEN` loop. Example:
+The keeping is done before the `PRINT`ing, so that `^S` does not
+defeat its purpose. The user can decide how much to keep around by
+setting the length of each `LIST`. Even if `L-OUTS` is not used, the
+atom `LAST-OUT` is always `SET` to the last object returned by `EVAL`
+in the standard `LISTEN` loop. Example:
<SET L-INS (NEWEST NEWER NEW)>$
(NEWEST NEWER NEW)
16.7. Control-G (\^G)
-Typing control-G (\^G, `<ASCII 7>`) at Muddle causes it to act just as
-if an error had occurred in whatever was currently being done. You can
-then examine the values of variables as above, continue by applying
-`ERRET` to one argument (which is ignored), `RETRY` a `FRAME` lower on
-the control stack, or flush everything by applying `ERRET` to no
-arguments.
+Typing control-G (`^G`, `<ASCII 7>`) at Muddle causes it to act just
+as if an error had occurred in whatever was currently being done. You
+can then examine the values of variables as above, continue by
+applying `ERRET` to one argument (which is ignored), `RETRY` a `FRAME`
+lower on the control stack, or flush everything by applying `ERRET` to
+no arguments.
16.8. Control-S (\^S)
-Typing control-S (
\^S, `<ASCII 19>`) at Muddle causes it to stop what
+Typing control-S (
`^S`, `<ASCII 19>`) at Muddle causes it to stop what
is happening and return to the `FRAME` `.LERR\ !-INTERRUPTS`,
-returning the `ATOM` `T`. (In the Tenex and Tops-20 versions, \^O also
-has the same effect.)
+returning the `ATOM` `T`. (In the Tenex and Tops-20 versions, `^O`
+also has the same effect.)
16.9. OVERFLOW
<DEFINE SUM3 (A)
<REPEAT ((S .A))
#DECL ((A S0 <OR FIX FLOAT>)
- <SET S <RESUME <+ .S <RESUME "GOT 1"> <RESUME "GOT
- 2">>>>>>
+ <SET S <RESUME <+ .S <RESUME "GOT 1"> <RESUME "GOT 2">>>>>>
20.7. Other Coroutining Features
--------------------------------
which it was typed.
In the ITS version, the "interesting" characters are those "enabled
-for interrupts" on a real terminal, namely <kbd>\^@</kbd> through
-<kbd>\^G</kbd>, <kbd>\^K</kbd> through <kbd>\^\_</kbd>, and
-<kbd>DEL</kbd> (that is, ASCII codes 0-7, 13-37, and 177 octal.)
+for interrupts" on a real terminal, namely `^@` through `^G`, `^K`
+through `^_`, and `DEL` (that is, ASCII codes 0-7, 13-37, and 177
+octal.)
In the Tenex and Tops-20 versions, the operating system can be told
which characters typed on a terminal should cause this interrupt to
containing those characters (no more than six, all with ASCII codes
less than 33 octal). If called with no argument, `ACTIVATE-CHARS`
returns a `STRING` containing the characters that currently interrupt.
-Initially, only <kbd>\^G</kbd>, <kbd>\^S</kbd>, and <kbd>\^O</kbd>
-interrupt.
+Initially, only `^G`, `^S`, and `^O` interrupt.
An initial Muddle already has `"CHAR"` enabled on `,INCHAN` with a
priority 8 (eight), the `SUBR` `QUITTER` for a handler to run in
-`#PROCESS 0` (the running `PROCESS`); this is how <kbd>`^G`</kbd> and
-<kbd>`^S`</kbd> are processed. In addition, every time a new `CHANNEL`
-is `OPEN`ed in `"READ"` mode to a terminal, a similar `IHEADER` and
-`HANDLER` are associated with that new `CHANNEL` automatically. These
+`#PROCESS 0` (the running `PROCESS`); this is how `^G` and `^S` are
+processed. In addition, every time a new `CHANNEL` is `OPEN`ed in
+`"READ"` mode to a terminal, a similar `IHEADER` and `HANDLER` are
+associated with that new `CHANNEL` automatically. These
automatically-generated `IHEADER`s and `HANDLER`s use the standard
machinery, and they can be `DISABLE`d or `OFF`ed at will. **However**,
the `IHEADER` for `,INCHAN` should not be `OFF`ed: Muddle knows that
`$` is typed only by an interrupt!
Example: the following causes the given message to be printed out
-whenever a <kbd>`^Y`</kbd> is typed on `.INCHAN`:
+whenever a `^Y` is typed on `.INCHAN`:
<SET H <HANDLER <GET .INCHAN INTERRUPT>
#FUNCTION ((CHAR CHAN)
### 21.8.8. "UNBLOCKED"
-`"UNBLOCKED"` occurs whenever a `$` (<kbd>`ESC`</kbd>) is typed on a
-terminal if a program was hanging and waiting for input, or when a TYI
-call (which see) is satisfied. A handler takes one argument: the
-`CHANNEL` via which the `$` or character is input.
+`"UNBLOCKED"` occurs whenever a `$` (`ESC`) is typed on a terminal if
+a program was hanging and waiting for input, or when a TYI call (which
+see) is satisfied. A handler takes one argument: the `CHANNEL` via
+which the `$` or character is input.
### 21.8.9. "READ" and "WRITE"
if an *unmanifest* is referenced more than twice. Example:
<DEFINE MAP-LOOKUP (THINGS "AUX" (DB ,DATA-BASE))
- #DECL ((VALUE) VECTOR (THINGS DB) <UNSPECIAL <PRIMTYPE
- LIST>>)
+ #DECL ((VALUE) VECTOR (THINGS DB) <UNSPECIAL <PRIMTYPE LIST>>)
<MAPF ,VECTOR <FUNCTION (T) <MEMQ .T .DB>> .THINGS>>
24.4. Global and Local Values
You can see the nature of the choices. Nesting is still and all better
than `GO`.
+
+Appendix 1. A Look Inside
+=========================
+
+This appendix tells about the mapping between Muddle objects and
+PDP-10 storage -- in other words, the way things look "on the inside".
+None of this information is essential to knowing how to program in
+Muddle, but it does give some reasons for capabilities and
+restrictions that otherwise you have to memorize. The notation and
+terminology get a little awkward in this discussion, because we are in
+a twilight zone between the worlds of Muddle objects and of bit
+patterns. In general the words and phrases appearing in diagrams refer
+to bit patterns not Muddle objects. A lower-case word (like "tuple")
+refers to the storage occupied by an object of the corresponding
+`PRIMTYPE` (like `TUPLE`).
+
+First some terminology needs discussion. The sine qua non of any
+Muddle object is a **pair** of 36-bit computer words. In general,
+lists consist of pairs chained together by pointers (addresses), and
+vectors consist of contiguous blocks of pairs. `==?` essentially tests
+two pairs to see whether they contain the same bit patterns.
+
+The first (lower-addressed) word of a pair is called the **`TYPE`
+word**, because it contains a numeric **`TYPE` code** that represents
+the object's `TYPE`. The second (higher-addressed) word of a pair is
+called the **value word**, because it contains (part of or the
+beginning of) the "data part" of the object. The `TYPE` word (and
+sometimes the value word) is considered to be made of a left half and
+a right half. We will picture a pair like this:
+
+ ---------------------------------
+ | TYPE | |
+ | - - - - - - - - - - - - - - - |
+ | value |
+ ---------------------------------
+
+where a vertical bar in the middle of a word means the word's halves
+are used independently. You can see that the `TYPE` code is confined
+to the left half of the `TYPE` word. (Half-)words are sometimes
+subdivided into **fields** appropriate for the context; fields are
+also pictured as separated by vertical bars. The right half of the
+`TYPE` word is used for different purposes depending on the `TYPE` of
+the object and actual location of the value.
+
+Actually the 18-bit `TYPE` field is further decoded. The high-order
+(leftmost) bit is the mark bit, used exclusively by the garbage
+collector when it runs. The next two bits are monitor bits, used to
+cause `"READ"` and `"WRITE"` interrupts on read and write references
+to the pair. The next bit is used to differentiate between list
+elements and vector dope words. The next bit is unused but could be
+used in the future for an "execute" monitor. The remaining 13 bits
+specify the actual `TYPE` code. What `CHTYPE` does is to copy the pair
+and put a new `TYPE` code into the new pair.
+
+Each data `TYPE` (predefined and `NEWTYPE`s) must belong to one of
+about 25 "storage allocation classes" (roughly corresponding to Muddle
+`PRIMTYPE`s). These classes are characterized primarily by the manner
+in which the garbage collector treats them. Some of these classes will
+now be described.
+
+"One Word"
+
+This class includes all data that are not pointers to some kind of
+structure. All external (program-available) `TYPE`s in this class are
+of `PRIMTYPE` `WORD`. Example:
+
+ ---------------------------------
+ | FIX | 0 |
+ | - - - - - - - - - - - - - - - |
+ | 105 |
+ ---------------------------------
+
+"Two Word"
+
+The members of this class are all 18-bit pointers to list elements.
+All external `TYPE`s in this class are of `PRIMTYPE` `LIST`. Example:
+
+ ---------------------------------
+ | LIST | 0 |
+ | - - - - - - - - - - - - - - - |
+ | 0 | pointer |
+ ---------------------------------
+
+where `pointer` is a pointer to the first list element. If there are
+no elements, `pointer` is zero; thus empty objects of `PRIMTYPE`
+`LIST` are `==?` if their `TYPE`s are the same.
+
+"Two N Word"
+
+Members of this class are all "counting pointers" to blocks of
+two-word pairs. The right half of a counting pointer is an address,
+and the left half is the negative of the number of 36-bit words in the
+block. (This format is tailored to the PDP-10 `AOBJN` instruction.)
+The number of pairs in the block (`LENGTH`) is half that number, since
+each pair is two words. All external `TYPE`s in this class are of
+`PRIMTYPE` `VECTOR`. Example:
+
+ ---------------------------------
+ | VECTOR | 0 |
+ | - - - - - - - - - - - - - - - |
+ | -2*length | pointer |
+ ---------------------------------
+
+where `length` is the `LENGTH` of the `VECTOR` and `pointer` is the
+location of the start (the element selected by an `NTH` argument of 1)
+of the `VECTOR`.
+
+"N word"
+
+This class is the same as the previous one, except that the block
+contains objects all of the same `TYPE` without individual `TYPE`
+words. The `TYPE` code for all the elements is in vector dope words,
+which are at addresses just larger than the block itself. Thus, any
+object that carries information in its `TYPE` word cannot go into the
+block: `PRIMTYPE`s `STRING`, `BYTES`, `TUPLE` (and the corresponding
+locatives `LOCS`, `LOCB`, `LOCA`), `FRAME`, and `LOCD`. All external
+`TYPE`s in this class are of `PRIMTYPE` `UVECTOR`. Example:
+
+ ---------------------------------
+ | UVECTOR | 0 |
+ | - - - - - - - - - - - - - - - |
+ | -length | pointer |
+ ---------------------------------
+
+where `length` is the `LENGTH` of the `UVECTOR` and `pointer` points
+to the beginning of the `UVECTOR`.
+
+"Byte String" and "Character String"
+
+These two classes are almost identical. Byte strings are byte pointers
+to strings of arbitrary-size bytes. `PRIMTYPE` `BYTES` is the only
+member of this class. Character strings are byte pointers to strings
+of ASCII characters. `PRIMTYPE` `STRING` is the only member of this
+class. Both of these classes consist of a length and a PDP-10 byte
+pointer. In the case of character strings, the byte-size field in the
+byte pointer is always seven bits per byte (hence five bytes per
+word). Example:
+
+ ---------------------------------
+ | STRING | length |
+ | - - - - - - - - - - - - - - - |
+ | byte-pointer |
+ ---------------------------------
+
+where `length` is the `LENGTH` of the `STRING` (in bytes) and
+`byte-pointer` points to a byte just before the beginning of the
+string (an `ILDB` instruction is needed to get the first byte). A
+newly-created `STRING` always has `*010700*` in the left half of
+`byte-pointer`. Unless the string was created by `SPNAME`,
+`byte-pointer` points to a uvector, where the elements (characters) of
+the `STRING` are stored, packed together five to a word.
+
+"Frame"
+
+This class gives the user program a handle on its control and
+variable-reference structures. All external `TYPE`s in this class are
+of `PRIMTYPE` `FRAME`. Three numbers are needed to designate a frame:
+a unique 18-bit identifying number, a pointer to the frame's storage
+on a control stack, and a pointer to the `PROCESS` associated with the
+frame. Example:
+
+ ---------------------------------
+ | FRAME |PROCESS-pointer|
+ | - - - - - - - - - - - - - - - |
+ | unique-id | frame-pointer |
+ ---------------------------------
+
+where `PROCESS-pointer` points to the dope words of a `PROCESS`
+vector, and `unique-id` is used for validating (testing `LEGAL?`) the
+`frame-pointer`, which points to a frame for some Subroutine call on
+the control stack.
+
+"Tuple"
+
+A tuple pointer is a counting pointer to a vector on the control
+stack. It may be a pointer to the arguments to a Subroutine or a
+pointer generated by the `"TUPLE"` declaration in a `FUNCTION`. Like
+objects in the previous class, these objects contain a unique
+identifying number used for validation. `PRIMTYPE` `TUPLE` is the only
+member of this class. Example:
+
+ ---------------------------------
+ | TUPLE | unique-id |
+ | - - - - - - - - - - - - - - - |
+ | -2*length | pointer |
+ ---------------------------------
+
+Other Storage Classes
+
+The rest of the storage classes include strictly internal `TYPE`s and
+pointers to special kinds of lists and vectors like locatives, `ATOM`s
+and `ASOC`s. A pair for any `LOCATIVE` except a `LOCD` looks like a
+pair for the corresponding structure, except of course that the `TYPE`
+is different. A `LOCD` pair looks like a tuple pair and needs a word
+and a half for its value; the `unique-id` refers to a binding on the
+control stack or to the "global stack" if zero. Thus `LOCD`s are in a
+sense "stack objects" and are more restricted than other locatives.
+
+An `OFFSET` is stored with the `INDEX` in the right half of the value
+word and the Pattern in the left half. Since the Pattern can be either
+an `ATOM` or a `FORM`, the left half actually points to a pair, which
+points to the actual Pattern. The Patttern `ANY` is recognized as a
+special case: the left-half pointer is zero, and no pair is used.
+Thus, if you're making the production version of your program and want
+to save some storage, can do something like
+`<SETG FOO <PUT-DECL ,FOO ANY>>` for all `OFFSET`s.
+
+Basic Data Structures
+---------------------
+
+Lists
+
+List elements are pairs linked together by the right halves of their
+first words. The list is terminated by a zero in the right half of the
+last pair. For example the `LIST` `(1 2 3)` would look like this:
+
+ -------------
+ | LIST | 0 |
+ | - - - - - | ----------- ----------- -----------
+ | 0 | ------>| FIX | ------->| FIX | ------->| FIX | 0 |
+ ------------- | - - - - | | - - - - | | - - - - |
+ | 1 | | 2 | | 3 |
+ ----------- ----------- -----------
+
+The use of pointers to tie together elements explains why new elements
+can be added easily to a list, how sharing and circularity work, etc.
+The links go in only one direction through the list, which is why a
+list cannot be `BACK`ed or `TOP`ped: there's no way to find the
+`REST`ed elements.
+
+Since some Muddle values require a word and a half for the value in
+the pair, they do not fit directly into list elements. This problem is
+solved by having "deferred pointers". Instead of putting the datum
+directly into the list element, a pointer to another pair is used as
+the value with the special internal `TYPE` `DEFER`, and the real datum
+is put in the deferred pair. For example the `LIST` `(1 "hello" 3)`
+would look like this:
+
+ -------------
+ | LIST | 0 |
+ | - - - - - | ----------- ----------- -----------
+ | 0 | ------>| FIX | ------->|DEFER| ------->| FIX | 0 |
+ ------------- | - - - - | | - - - - | | - - - - |
+ | 1 | | ----- | 3 |
+ ----------- ----------- | -----------
+ |
+ ----------- |
+ |STRING| 5|<-
+ | - - - - |
+ |byte-pntr|
+ -----------
+
+Vectors
+
+A vector is a block of contiguous words. More than one pair can point
+to the block, possibly at different places in the block; this is how
+sharing occurs among vectors. Pointers that are different arise from
+`REST` or `GROW`/`BACK` operations. The block is followed by two "dope
+words", at addresses just larger than the largest address in the
+block. Dope words have the following format:
+
+ / /
+ | |
+ | |
+ ---------------------------------
+ | type | grow |
+ | - - - - - - - - - - - - - - - |
+ | length | gc |
+ ---------------------------------
+
+The various fields have the following meanings:
+
+`type` -- The fourth bit from the left (the "vector bit", `40000`
+octal) is always one, to distinguish these vector dope words from a
+`TYPE`/value pair.
+
+If the high-order bit is zero, then the vector is a `UVECTOR`, and the
+remaining bits specify the uniform `TYPE` of the elements. `CHUTYPE`
+just puts a new `TYPE` code in this field. Each element is limited to
+a one-word value: clearly `PRIMTYPE` `STRING`s and `BYTES`es and stack
+objects can't go in uniform vectors.
+
+If the high-order bit is one and the `TYPE` bits are zero, then this
+is a regular `VECTOR`.
+
+If the high-order bit is one and the `TYPE` bits are not all zero,
+then this is either an `ATOM`, a `PROCESS`, an `ASOC`, or a
+`TEMPLATE`. The special internal format of these objects will be
+described a little later in this appendix.
+
+`length` -- The high-order bit is the mark bit, used by the garbage
+collector. The rest of this field specifies the number of words in the
+block, including the dope words. This differs from the length given in
+pairs pointing to this vector, since such pairs may be the result of
+`REST` operations.
+
+`grow` -- This is actually two nine-bit fields, specifying either
+growth or shrinkage at both the high and low ends of the vector. The
+fields are usually set only when a stack must be grown or shrunk.
+
+`gc` -- This is used by the garbage collector to specify where this
+vector is moving during compaction.
+
+Examples (numbers in octal): the `VECTOR` `[1 "bye" 3]` looks like:
+
+ ---------------
+ | VECTOR | 0 |
+ | - - - - - - | -----------------
+ | -6 | ----------->| FIX | |
+ --------------- | - - - - - - - |
+ | 1 |
+ -----------------
+ | STRING | 3 |
+ | - - - - - - - |
+ | byte pointer |
+ -----------------
+ | FIX | |
+ | - - - - - - - |
+ | 3 |
+ -----------------
+ | 440000 | 0 |
+ | - - - - - - - |
+ | 10 | |
+ -----------------
+
+The `UVECTOR` `![-1 7 -4!]` looks like:
+
+ ---------------
+ | UVECTOR | 0 |
+ | - - - - - - | -----------------
+ | -3 | ----------->| -1 |
+ --------------- -----------------
+ | 7 |
+ -----------------
+ | -4 |
+ -----------------
+ | 40000+FIX | 0 |
+ | - - - - - - - |
+ | 5 | |
+ -----------------
+
+Atoms
+
+Internally, atoms are special vector-like objects. An atom contains a
+value cell (the first two words of the block, filled in whenever the
+global or local value of the `ATOM` is referenced and is not already
+there), an `OBLIST` pointer, and a print name (`PNAME`), in the
+following format:
+
+ ---------------------------------
+ | type | bindid |
+ ---------------------------------
+ | pointer-to-value |
+ ---------------------------------
+ | pointer-to-oblist |
+ ---------------------------------
+ | print-name |
+ / /
+ / /
+ |(ASCII with NUL padding on end)|
+ ---------------------------------
+ | ATOM | valid-type |
+ | - - - - - - - - - - - - - - - |
+ | length | gc |
+ ---------------------------------
+
+If the type field corresponds to `TYPE` `UNBOUND`, then the `ATOM` is
+locally and globally unbound. (This is different from a pair, where
+the same `TYPE` `UNBOUND` is used to mean unassigned.) If it
+corresponds to `TYPE` `LOCI` (an internal `TYPE`), then the value cell
+points either to the global stack, if `bindid` is zero, or to a local
+control stack, if `bindid` is non-zero. The `bindid` field is used to
+verify whether the local value pointed to by the value cell is valid
+in the current environment. The `pointer-to-OBLIST` is either a
+counting pointer to an oblist (uvector). a positive offset into the
+"transfer vector" (for pure `ATOM`s), or zero, meaning that this
+`ATOM` is not on an `OBLIST`. The `valid-type` field tells whether or
+not the `ATOM` represents a `TYPE` and if so the code for that `TYPE`:
+`grow` values are never needed for atoms.
+
+Associations
+
+Associations are also special vector-like objects. The first six words
+of the block contain `TYPE`/value pairs for the `ITEM`, `INDICATOR`
+and `AVALUE` of the `ASOC`. The next word contains forward and
+backward pointers in the chain for that bucket of the association hash
+table. The last word contains forward and backward pointers in the
+chain of all the associations.
+
+ ---------------------------------
+ | ITEM |
+ | - - - - - - - - - - - - - - - |
+ | pair |
+ ---------------------------------
+ | INDICATOR |
+ | - - - - - - - - - - - - - - - |
+ | pair |
+ ---------------------------------
+ | AVALUE |
+ | - - - - - - - - - - - - - - - |
+ | pair |
+ ---------------------------------
+ | bucket-chain-pointers |
+ ---------------------------------
+ | association-chain-pointers |
+ ---------------------------------
+ | ASOC | 0 |
+ | - - - - - - - - - - - - - - - |
+ | 12 octal | gc |
+ ---------------------------------
+
+`PROCESS`es
+
+A `PROCESS` vector looks exactly like a vector of `TYPE`/value pairs.
+It is different only in that the garbage collector treats it
+differently from a normal vector, and it contains extremely volatile
+information when the `PROCESS` is `RUNNING`.
+
+Templates
+
+In a template, the number in the type field (left half or first dope
+word) identifies to which "storage allocation class" this `TEMPLATE`
+belongs, and it is used to find PDP-10 instructions in internal tables
+(frozen uvectors) for performing `LENGTH`, `NTH`, and `PUT` operations
+on any object of this `TYPE`. The programs to build these tables are
+not part of the interpreter, but the interpreter does know how to use
+them properly. The compiler can put these instructions directly in
+compiled programs if a `TEMPLATE` is never `REST`ed; otherwise it must
+let the interpreter discover the appropriate instruction. The value
+word of a template pair contains, not a counting pointer, but the
+number of elements that have been `REST`ed off in the left half and a
+pointer to the first dope word in the right half.
+
+The Control Stack
+-----------------
+
+Accumulators with symbolic names `AB`, `TB`, and `TP` are all pointers
+into the `RUNNING` `PROCESS`'s control stack. `AB` ("argument base")
+is a pointer to the arguments to the Subroutine now being run. It is
+set up by the Subroutine-call mediator, and its old value is always
+restored after a mediated Subroutine call returns. `TB` ("temporaries
+base") points to the frame for the running Subroutine and also serves
+as a stack base pointer. The `TB` pointer is really all that is
+necessary to return from a Subroutine -- given a value to return, for
+example by `ERRET` -- since the frame specifies the entire state of
+the calling routine. `TP` ("temporaries pointer") is the actual stack
+pointer and always points to the current top of the control stack.
+
+While we're on the subject of accumulators, we might as well be
+complete. Each accumulator contains the value word of a pair, the
+corresponding `TYPE` words residing in the `RUNNING` `PROCESS` vector.
+When a `PROCESS` is not `RUNNING` (or when the garbage collector is
+running), the accumulator contents are stored in the vector, so that
+the Objects they point to look like elements of the `PROCESS` and thus
+are not garbage-collectible.
+
+Accumulators `A`, `B`, `C`, `D`, `E` and `O` are used almost entirely
+as scratch accumulators, and they are not saved or restored across
+Subroutine calls. Of course the interrupt machinery always saves these
+and all other accumulators. `A` and `B` are used to return a pair as
+the value of a Subroutine call. Other than that special feature, they
+are just like the other scratch accumulators.
+
+`M` and `R` are used in running `RSUBR`s. `M` is always set up to
+point to the start of the `RSUBR`'s code, which is actually just a
+uniform vector of instructions. All jumps and other references to the
+code use `M` as an index register. This makes the code
+location-insensitive, which is necessary because the code uvector will
+move around. `R` is set up to point to the vector of objects needed by
+the `RSUBR`. This accumulator is necessary because objects in
+garbage-collected space can move around, but the pointers to them in
+the reference vector are always at the same place relative to its
+beginning.
+
+`FRM` is the internal frame pointer, used in compiled code to keep
+track of pending Subroutine calls when the control stack is heavily
+used. `P` is the internal-stack pointer, used primarily for internal
+calls in the interpreter.
+
+One of the nicest features of the Muddle environment is the uniformity
+of the calling and returning sequence. All Subroutines -- both
+built-in F/SUBRs and compiled `RSUBR(-ENTRY)`s -- are called in
+exactly the same way and return the same way. Arguments are always
+passed on the control stack and results always end up in the same
+accumulators. For efficiency reasons, a lot of internal calls within
+the interpreter circumvent the calling sequence. However, all calls
+made by the interpreter when running user programs go through the
+standard calling sequence.
+
+A Subroutine call is initiated by one of three UUOs (PDP-10
+instructions executed by software rather than hardware). `MCALL`
+("Muddle call") is used when the number of arguments is known at
+assemble or compile time, and this number is less than 16. `QCALL`
+("quick call") may be used if, in addition, an `RSUBR(-ENTRY)` is
+being called that can be called "quickly" by virtue of its having
+special information in its reference vector. `ACALL` ("accumulator
+call") is used otherwise. The general method of calling a Subroutine
+is to `PUSH` (a PDP-10 instruction) pairs representing the arguments
+onto the control stack via `TP` and then either (1) `MCALL` or `QCALL`
+or (2) put the number of arguments into an accumulator and `ACALL`.
+Upon return the object returned by the Subroutine will be in
+accumulators `A` and `B`, and the arguments will have been `POP`ped
+off the control stack.
+
+The call mediator stores the contents of `P` and `TP` and the address
+of the calling instruction in the current frame (pointed to by `TB`).
+It also stores Muddle's "binding pointer" to the topmost binding in
+the control stack. (The bindings are linked together through the
+control stack so that searching through them is more efficient than
+looking at every object on the stack.) This frame now specifies the
+entire state of the caller when the call occurred. The mediator then
+builds a new frame on the control stack and stores a pointer back to
+the caller's frame (the current contents of `TB`), a pointer to the
+Subroutine being called, and the new contents of `AB`, which is a
+counting pointer to the arguments and is computed from the information
+in the `MCALL` or `QCALL` instruction or the `ACALL` accumulator. `TB`
+is then set up to point to the new frame, and its left half is
+incremented by one, making a new `unique-id`. The mediator then
+transfers control to the Subroutine.
+
+A control stack frame has seven words as shown:
+
+ ---------------------------------
+ | ENTRY | called-addr |
+ ---------------------------------
+ | unique-id | prev frame |
+ ---------------------------------
+ | argument pointer |
+ ---------------------------------
+ | saved binding pointer |
+ ---------------------------------
+ | saved P |
+ ---------------------------------
+ | saved TP |
+ ---------------------------------
+ | saved calling address |
+ ---------------------------------
+
+The first three words are set up during the call to the Subroutine.
+The rest are filled in when this routine calls another Subroutine. The
+left half of `TB` is incremented every time a Subroutine call occurs
+and is used as the `unique-id` for the frame, stored in frame and
+tuple pairs as mentioned before. Obviously this `id` is not strictly
+unique, since each 256K calls it wraps around to zero. The right half
+of `TB` is always left pointing one word past the
+saved-calling-address word in the frame. `TP` is also left pointing at
+that word, since that is the top of the control stack at Subroutine
+entry. The arguments to the called Subroutine are below the frame on
+the control stack (at lower storage addresses), and the temporaries
+for the called Subroutine are above the frame (at higher storage
+addresses). These arguments and temporaries are just pairs stored on
+the control stack while needed: they are all that remain of
+`UNSPECIAL` values in compiled programs.
+
+The following figure shows what the control stack might look like
+after several Subroutine calls.
+
+ / /
+ | |
+ -----------------
+ | |
+ | args for S1 |
+ | |
+ -----------------
+ | frame for S1 |
+ ----------------- <--
+ | | |
+ | temps for S1 | |
+ | | |
+ ----------------- |
+ | | |
+ | args for S2 | |
+ | | |
+ ----------------- |
+ | frame for S2 | ---
+ ----------------- <------
+ | | |
+ | temps for S2 | |
+ | | |
+ ----------------- |
+ | args for S3 | |
+ ----------------- |
+ | frame for S3 | -------
+ -----------------
+ | |
+ | temps for S3 |
+ | |
+ | |
+ -----------------
+ (top)
+
+The above figure shows the frames all linked together through the
+control stack (the "execution path"), so that it is easy to return to
+the caller of a given Subroutine (`ERRET` or `RETRY`).
+
+Subroutine exit is accomplished simply by the call mediator, which
+loads the right half of `TB` from the previous frame pointer, restores
+the "binding pointer", `P`, and `TP`, and transfers control back to
+the instruction following the saved calling address.
+
+Variable Bindings
+-----------------
+
+All local `ATOM` values are kept on the control stack of the `PROCESS`
+to which they are local. As described before, the atom contains a word
+that points to the value on the control stack. The pointer is actually
+to a six-word "binding block" on the control stack. Binding blocks
+have the following format:
+
+ ---------------------------------
+ | BIND or UBIND | prev |
+ ---------------------------------
+ | pointer to ATOM |
+ ---------------------------------
+ | value |
+ | - - - - - - - - - - - - - - - |
+ | pair |
+ ---------------------------------
+ | decl | unique-id |
+ ---------------------------------
+ | previous-binding |
+ ---------------------------------
+
+where:
+
+- `BIND` means this is a binding for a `SPECIAL` `ATOM` (the only
+ kind used by compiled programs), and `UBIND` means this is a
+ binding for an `UNSPECIAL` `ATOM` -- for `SPECIAL` checking by the
+ interpreter;
+- `prev` points to the closest previous binding block for any `ATOM`
+ (the "access path" -- `UNWIND` objects are also linked in this
+ chain);
+- `decl` points to a `DECL` associated with this value, for
+ `SET(LOC)` to check;
+- `unique-id` is used for validation of this block; and
+- `previous-binding` points to the closest previous binding for this
+ `ATOM` (used in unbinding).
+
+Bindings are generated by an internal subroutine called `SPECBIND`
+(name comes from `SPECIAL`). The caller to `SPECBIND` `PUSH`es
+consecutive six-word blocks onto the control stack via `TP` before
+calling `SPECBIND`. The first word of each block contains the `TYPE`
+code for `ATOM` in its left half and all ones in its right half.
+`SPECBIND` uses this bit pattern to identify the binding blocks.
+`SPECBIND`'s caller also fills in the next three words and leaves the
+last two words empty. `SPECBIND` fills in the rest and leaves the
+"binding pointer" pointing at the topmost binding on the control
+stack. `SPECBIND` also stores a pointer to the current binding in the
+value cell of the atom.
+
+Unbinding is accomplished during Subroutine return. When the previous
+frame is being restored, the call mediator checks to see if the saved
+"binding pointer" and the current one are different; if they are,
+`SPECSTORE` is called. `SPECSTORE` runs through the binding blocks,
+restoring old value pointers in atoms until the "binding pointer" is
+equal to the one saved in the frame.
+
+Obviously variable binding is more complicated than this, because
+`ATOM`s can have both local and global values and even different local
+values in different `PROCESS`es. The solution to all of these
+additional problems lies in the `bindid` field of the atom. Each
+`PROCESS` vector also contains a current `bindid`. Whenever an ATOM's
+local value is desired, the `RUNNING` `PROCESS`'s `bindid` is checked
+against that of the atom: if they are the same, the atom points to the
+current value; if not, the current `PROCESS`'s control stack must be
+searched to find a binding block for this `ATOM`. This binding scheme
+might be called "shallow binding". The searching is facilitated by
+having all binding blocks linked together. Accessing global variables
+is accomplished in a similar way, using a `VECTOR` that is referred to
+as the "global stack". The global stack has only an `ATOM` and a value
+slot for each variable, since global values never get rebound.
+
+`EVAL` with respect to a different environment causes some additional
+problems. Whenever this kind of `EVAL` is done, a brand new `bindid`
+is generated, forcing all current local value cells of atoms to appear
+invalid. Local values must now be obtained by searching the control
+stack, which is inefficient compared to just pulling them out of the
+atoms. (The greatest inefficiency occurs when an `ATOM`'s `LVAL` is
+never accessed twice in a row in the same environment.) A special
+block is built on the control stack and linked into the binding-block
+chain. This block is called a "skip block" or "environment splice",
+and it diverts the "access path" to the new environment, causing
+searches to become relative to this new environment.
projects / mudman.git / blobdiff