There are essentially two ways that MEND could follow the flow of
control of the application program. The most direct way, as attempted
-by MUMBLE[^14] and discussed in the last chapter, would be for MEND
-to execute the application program by simulating the operation of
+by MUMBLE[^7] and discussed in the last chapter, would be for MEND to
+execute the application program by simulating the operation of
Muddle. This type of simulation has been shown to require a complex
end all too often fragile structure. The debugging program would need
to be constantly updated to match changes and additions to the Muddle
representation of the stack is displayed as a number of lines, each
corresponding to one level. Each line shows a level number and the
displayed object printed in "&-printing", named for the printing
-function &[^15] created by Greg Pfister. Although strictly speaking
+function &[^14] created by Greg Pfister. Although strictly speaking
the stack builds upward (towards higher memory locations), it seams
more natural to display and speak of the stack as building from the
top downward, in the direction that printing normally occurs. As each
One such feature is the existence of compiled code. Although Muddle
was originally intended to be a high-level interpretive language, an
-assembler was written[^16], producing machine code that executes in
+assembler was written[^15], producing machine code that executes in
the Muddle environment, to allow programmers to create "primitives"
that perform functions not otherwise available in Muddle. Once the
-assembler was written, it was natural that a compiler[^17] followed.
+assembler was written, it was natural that a compiler[^16] followed.
It translates normal Muddle code into Muddle assembly code which is
then assembled. Typically Muddle programs are tested interpretively
and, when fully debugged, complied in order to obtain a major
debugging system. It provides a simple user interface to Muddle's
single-stepping functions that makes single-stepping through a Muddle
program appear similar to single-stepping through an
-assembly-language program with DDT[^18][^19]. The choices of
-characters for invoking many of the MEND functions were based upon
-the characters used to invoke similar functions in DEBUGR. Many of
+assembly-language program with DDT[^2][^3]. The choices of characters
+for invoking many of the MEND functions were based upon the
+characters used to invoke similar functions in DEBUGR. Many of
DEBUGR's command invocation characters were in turn based upon those
in DDT. The object of all of this is to build character/command
associations in the user's mind that may be carried over from one
creating a new editor is "the kiss of death" for a Muddle subsystem.
A number of Muddle editors have been tried over the years and the
only one that finally became generally accepted (and is now
-pre-loaded in Muddle) is EDIT[^20] . Members of the Muddle community
+pre-loaded in Muddle) is EDIT[^11] . Members of the Muddle community
will tolerate minor changes to EDIT, but they will not accept a new
editing system. The situation is analogous to one of the major
obstacles blocking the acceptance of ESP. Programmers were accustomed
take suffix arguments. Currently the MEND table includes the
following commands. (FIX here means a Muddle object of type FIX,
i.e., a fixed-point number. FLOAT means a floating-point number.
-PPRINT[^21] is a function that prints a Muddle object in a format
+PPRINT[^14] is a function that prints a Muddle object in a format
which indicates the positions of its elements and sub-elements in the
tree hierarchy.)
of what constitutes MEND is in another process safely removed and
hidden from the user. Even the small amount of overhead constituting
the command level function is hidden from functions such as
-FRAMES[^22], which may be used to view the levels of the application
+FRAMES[^13], which may be used to view the levels of the application
program's current control stack. The effect is much the same as that
of Muddle's listening loop which is invoked at the current bottom of
the stack in case of error, to allow the programmer to run any
application program or to simply back up to some previous point. This
was suggested in two varieties, an actual undoing of all effects of
the program on a step-by-step basis or simply showing previous states
-of the MSTACK. The first version would have used UNDO\[\^10\], a
-package of functions to actually back up a program to some previous
-state. UNDO however violates a primary design goal of MEND. It works
-by redefining every Muddle function that has a side-effect, thereby
+of the MSTACK. The first version would have used UNDO[^10], a package
+of functions to actually back up a program to some previous state.
+UNDO however violates a primary design goal of MEND. It works by
+redefining every Muddle function that has a side-effect, thereby
causing most of the negative effects of simulation that were
previously discussed. Unfortunately the way UNDO works is really the
only reasonable way such a package could work, short of modifying
specifications of the programmer. EDIT allows one to define one's own
commands or to redefine those of EDIT.
+ENVIRONMENT: A Muddle object which specifies a particular set of
+variable bindings. An ENVIRONMENT is normally cumulatively built up
+as the control stack of a program builds and ATOMs are bound. The
+ENVIRONMENT actually corresponds to a particular point on the control
+stack. A program may have an object evaluated in an ENVIRONMENT
+specifying the current state of another running program. The effect
+is as if the latter program had evaluated the object.
+
+ESP: A debugging system for assembly-language programs.
+
+EVAL: A build-in Muddle function that evaluated an object and returns
+the value of that object
+
+FIX: A Muddle object that is an integer.
+
+FLOAT: A Muddle object that is a floating-point number.
+
+FORM: A list of Muddle objects which is evaluated by applying the
+first element (some function) to the rest of the elements (its
+arguments). "Execution" in Muddle generally refers to the evaluation
+of a FORM. The evaluation of that FORM will often require the
+evaluation of other FORMs (the arguments to the function or FORMs in
+the body of the function ).
+
+FRAMES: A pre-loaded function that shows the programmer a printed
+representation of the control stack of the current program.
+
+IMED: An editor for Muddle objects that works by outputting an object
+to the IMLAC where the local editing functions are used.
+
+IMLAC: A minicomputer with a keyboard and CRT display used as an
+intelligent terminal.
+
+ITS: A general-purpose time-sharing operating system developed by the
+Artificial Intelligence Laboratory at M.I.T.
+
+LVAL: A built-in Muddle function that returns the local value of a
+given ATOM. The local value is that which was last bound to the ATOM
+In the current ENVIRONMENT.
+
+Muddle: An applicative programming language used to inclement MEND.
+
+MEND: Muddle Executor, aNalyzer, and Debugger. The subject of this
+report.
+
+MSC: Multi-Screen Console program for an IMLAC. This gives the IMLAC
+used as a terminal a capability for having several virtual screens
+that may be accessed and displayed independently.
+
+MSTACK: A structure that MEND builds to contain a representation of
+the control stack of the application program.
+
+MUMBLE: An early debugging aid for Muddle programs providing a
+display of the application program's control stack.
+
+PPRINT: A pre-loaded Muddle function that "Pretty-PRINTs" an object
+in a format which indicates the positions of its elements and
+sub-elements in the tree hierarchy.
+
+PRINTTYPE: A built-in Muddle function allowing the programmer to
+specify exactly how any particular type of object should be printed.
+May be used to output characters that will be interpreted as special
+commands on input. See READ-TABLE.
+
+PROG: A built-in Muddle function used for sequential execution of
+Muddle objects (generally FORMs). This function provides for binding
+of ATOMs to be used within the PROG's scope and then evaluates each
+of the objects in its body, usually in order. It is possible,
+however, to alter the flow of control by branching forward or
+backward to another part of the PROG body. See REPEAT.
+
+READ-TABLE: A table that may be set up in Muddle to specify how any
+character should be treated on input. See PRINTTYPE.
+
+REPEAT: Like PROG except that when the end of the body of objects is
+reached, control returns to the beginning.
+
+SSV: The normally used IMLAC console program. See MSC.
+
+UNDO: A Muddle program that stores information about the execution of
+an application program so that the execution may be backed up to some
+previous point at any time.
+
[^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer
Journal 1973, volume 7, number 3, pages 182-198
projects / mudman.git / blobdiff