Finishing section 1, adding initial footnotes, restyling markdown text

diff --git a/md/debugging.md b/md/debugging.md
index 9e19ab95e0addc2781123da359c702adb9b681b7..81c1c8e3d36211933ec383f30f1a0d499787b884 100644 (file)
--- a/md/debugging.md
+++ b/md/debugging.md
@@ -1,200 +1,382 @@
-% A Dynamic Debugging System For Muddle
-% Joel Mayer Berez
-% January 1978
+---
+title: 'A Dynamic Debugging System For Muddle'
+author: Joel Mayer Berez
+date: January 1978
+abstract: Program debugging is a time consuming process. Conventional
+  debugging techniques and aids typically give the user a narrow view
+  of the program's operation, making debugging difficult. A debugging
+  system that would present a clear overall picture of a program's
+  behavior and would be both flexible and simple to operate would be a
+  valuable tool. Such a system was designed and implemented in and for
+  Muddle, a high-level applicative programming language. This report
+  discusses the design alternatives considered during the debugging
+  system's design and implementation phases, the reasons for the
+  resulting design choices, and the system attributes. A major
+  attribute of the system (MEND) is that it does not simulate the
+  program being debugged but instead monitors it from another
+  process. This attribute results in a robust and viable debugging
+  system, because MEND need not be modified in order to handle each
+  new extension to Muddle and/or each new user-defined primitive.
+---

 
 MIT Technical Memo 94
 
 
 MIT Technical Memo 94
 

-Laboratory for Computer Science  
-Massachusetts Institute of Technology  
-545 Technology Square  
-Cambridge, Massachusetts 02139
-
-# Copyright
-
-This report was originally published in the United States in January 
-1978 without a copyright notice and without subsequent registration 
-with the U.S. Copyright Office within 5 years. Doing at least one of 
-those was a requirement of United States copyright law at that time 
-[^1]. This report is therefore in the public domain in the United 
-States for failure to comply with the required formalities. This means 
-you're free to download, modify and redistribute this report. People 
-outside of the United States must check the copyright laws of their 
-country before downloading or redistributing.
-
-[^1]: <http://copyright.cornell.edu/resources/publicdomain.cfm>
-
-# Abstract
-
-Program debugging is a time consuming process. Conventional debugging 
-techniques and aids typically give the user a narrow view of the 
-program's operation, making debugging difficult. A debugging system 
-that would present a clear overall picture of a program's behavior and 
-would be both flexible and simple to operate would be a valuable tool. 
-Such a system was designed and implemented in for Muddle, a high-level 
-applicative programming language. This report discusses: the design 
-alternatives considered during the debugging system's design and 
-implementation phases, the reasons for the resulting design choices, 
-and the system attributes. A major attribute of the system (MEND) is 
-that it does not simulate the program being debugged but instead 
-monitors it from another process. This attribute results in a robust 
-and viable debugging system, because MEND not be modified in order to 
-handle each new extension to Muddle and/or each new user-defined 
+Laboratory for Computer Science
+Massachusetts Institute of Technology
+545 Technology Square Cambridge, Massachusetts 02139
+
+Copyright
+=========
+
+This research was supported by the Advanced Research Projects Agency
+of the Department of Defense and was monitored by the Office of Naval
+Research under Contract No. N00014-75-C-0661.
+
+This report was originally published in the United States in January
+1978 without a copyright notice and without subsequent registration
+with the U.S. Copyright Office within 5 years. Doing at least one of
+those was a requirement of United States copyright law at that time.
+This report is therefore in the public domain in the United States for
+failure to comply with the required formalities. This means you're
+free to download, modify and redistribute this report. People outside
+of the United States must check the copyright laws of their country
+before downloading or redistributing.
+
+Abstract
+========
+
+Program debugging is a time consuming process. Conventional debugging
+techniques and aids typically give the user a narrow view of the
+program's operation, making debugging difficult. A debugging system
+that would present a clear overall picture of a program's behavior and
+would be both flexible and simple to operate would be a valuable tool.
+Such a system was designed and implemented in for Muddle, a high-level
+applicative programming language. This report discusses: the design
+alternatives considered during the debugging system's design and
+implementation phases, the reasons for the resulting design choices,
+and the system attributes. A major attribute of the system (MEND) is
+that it does not simulate the program being debugged but instead
+monitors it from another process. This attribute results in a robust
+and viable debugging system, because MEND not be modified in order to
+handle each new extension to Muddle and/or each new user-defined

 primitive.
 
 primitive.
 

-This report reproduces a thesis Of the same title submitted to the 
-Department of Electrical Engineering, Massachusetts Institute of 
-Technology, in partial fulfillment of the requirements for the Degree 
+This report reproduces a thesis of the same title submitted to the
+Department of Electrical Engineering, Massachusetts Institute of
+Technology, in partial fulfillment of the requirements for the Degree

 of Bachelor of Science.
 
 of Bachelor of Science.
 

-# Acknowledgements
+Acknowledgements
+================

 
 

-I wish to thank Al Vezza, for supervising this work and guiding me 
-along the road to winnage; Stu Galley, for the original idea; Bruce 
-Daniels and Gerald Farrell, for laying some of the ground work I have 
-built upon; Brian Berkowitz and Chris Reeve, for patiently repairing 
-my ailing Muddles; Marc Blank and Tak To, for support work and for 
-providing me with company during all-night console sessions; and all 
-of the other ITS and DynaMod hackers who have built a system well 
+I wish to thank Al Vezza, for supervising this work and guiding me
+along the road to winnage; Stu Galley, for the original idea; Bruce
+Daniels and Gerald Farrell, for laying some of the ground work I have
+built upon; Brian Berkowitz and Chris Reeve, for patiently repairing
+my ailing Muddles; Marc Blank and Tak To, for support work and for
+providing me with company during all-night console sessions; and all
+of the other ITS and DynaMod hackers who have built a system well

 worth using.
 
 worth using.
 

-This research was supported by the Advanced Research Projects Agency 
-of the Department of Defense and was monitored by the Office of Naval 
+This research was supported by the Advanced Research Projects Agency
+of the Department of Defense and was monitored by the Office of Naval

 Research under Contract No. N00014-75-C-0661.
 
 Research under Contract No. N00014-75-C-0661.
 

-# Introduction
+Introduction
+============

 
 

-## Background
+Background
+----------

 
 

-A time-consuming and frustrating aspect of computer programming is the 
-debugging of faulty programs. Current debugging techniques involve 
-tracing through the present operation of the program and mentally 
-comparing its action with one's concept of what should be happening. 
-With few exceptions, an understanding of where the program fails to 
-conform to "correct" operation must be made before the cause of the 
-failure can be determined and corrective action taken. This is where 
+A time-consuming and frustrating aspect of computer programming is the
+debugging of faulty programs. Current debugging techniques involve
+tracing through the present operation of the program and mentally
+comparing its action with one's concept of what should be happening.
+With few exceptions, an understanding of where the program fails to
+conform to "correct" operation must be made before the cause of the
+failure can be determined and corrective action taken. This is where

 much of the difficulty occurs.
 
 much of the difficulty occurs.
 

-In conventional debugging, it is rare for the programmer to have 
-available any more than the most basic aids. One usually has to 
-extrapolate from a bare minimum of information (such as machine 
-generated error messages) or one may be buried under a large excess of 
-information, most irrelevant (such as a core dump). Even with the more 
-advanced aids, the programmer typically gets but a small window in the 
-operation of the program through which, sooner or later, she or he 
-will locate the problem. A well-localized fault will be relatively 
-easy to spot compared to a global problem that the programmer may only 
+In conventional debugging, it is rare for the programmer to have
+available any more than the most basic aids. One usually has to
+extrapolate from a bare minimum of information (such as machine
+generated error messages) or one may be buried under a large excess of
+information, most irrelevant (such as a core dump). Even with the more
+advanced aids, the programmer typically gets but a small window in the
+operation of the program through which, sooner or later, she or he
+will locate the problem. A well-localized fault will be relatively
+easy to spot compared to a global problem that the programmer may only

 catch glimpses of through the debugging window.
 
 catch glimpses of through the debugging window.
 

-In a compiler language, the programmer's best hope is to insert 
-statements to print intermediate results or to try to separate the 
-program into easier-to-handle modules. There are a few more advanced 
-aids available, but their use is limited. One problem is that the 
-program is, in effect, first translated into a lower-level language 
-(generally "machine" language) and then executed interpretively in 
-that language. The original symbols and syntax of the source program 
-are lost, or saved only with great difficulty, making analysis and 
+In a compiler language, the programmer's best hope is to insert
+statements to print intermediate results or to try to separate the
+program into easier-to-handle modules. There are a few more advanced
+aids available[^1], but their use is limited. One problem is that the
+program is, in effect, first translated into a lower-level language
+(generally "machine" language) and then executed interpretively in
+that language. The original symbols and syntax of the source program
+are lost, or saved only with great difficulty, making analysis and

 manipulation of the executing program a very painful process.
 
 manipulation of the executing program a very painful process.
 

-If the programmer is using an interpretive language with facilities 
-for interaction, things are considerably easier. The common technique 
-is to stop execution at strategic points and examine the state of the 
-environment. Since this is done interactively, with the source program 
-still available in more or less its original form, the cause of the 
-problem can often be found in less time than it could otherwise. one 
-of the best example of this approach is the use of DDT (Dynamic 
-Debugging Tool/Technique).
-
-DDT basically works with machine-language programs. However, by freely 
-translating between numbers and symbols through the use of a table 
-generated by the assembler, DDT makes programs look to the programmer 
-like symbolic assembly-language programs. The user of DDT can operate 
-in free-run mode or in n-step (statement) mode, switching between them 
-at will. In either case one can set a breakpoint at any statement, 
-which will cause execution to stop just before the statement is 
-executed. Whenever stopped in DDT, the user can examine or change the 
-contents of any location. This can be done in several data modes 
-(e.g., unsigned octal, full ASCII, sixbit, etc.) including the use of 
-symbols to represent addresses. Arbitrary numeric expressions can also 
+If the programmer is using an interpretive language with facilities
+for interaction, things are considerably easier. The common technique
+is to stop execution at strategic points and examine the state of the
+environment. Since this is done interactively, with the source program
+still available in more or less its original form, the cause of the
+problem can often be found in less time than it could otherwise. one
+of the best example of this approach is the use of DDT (Dynamic
+Debugging Tool/Technique)[^2][^3].
+
+DDT basically works with machine-language programs. However, by freely
+translating between numbers and symbols through the use of a table
+generated by the assembler, DDT makes programs look to the programmer
+like symbolic assembly-language programs. The user of DDT can operate
+in free-run mode or in n-step (statement) mode, switching between them
+at will. In either case one can set a breakpoint at any statement,
+which will cause execution to stop just before the statement is
+executed. Whenever stopped in DDT, the user can examine or change the
+contents of any location. This can be done in several data modes
+(e.g., unsigned octal, full ASCII, sixbit, etc.) including the use of
+symbols to represent addresses. Arbitrary numeric expressions can also

 be evaluated without affecting the program.
 
 be evaluated without affecting the program.
 

-One main advantage of DDT is that the debugging environment is very 
-similar to the language environment the programmer used to write the 
-program. One has to learn only the DDT commands rather than an 
-entirely new language. Another advantage is the user's ability for 
-viewing the results of the changes. In addition, one can quickly see 
+One main advantage of DDT is that the debugging environment is very
+similar to the language environment the programmer used to write the
+program. One has to learn only the DDT commands rather than an
+entirely new language. Another advantage is the user's ability for
+viewing the results of the changes. In addition, one can quickly see

 the results of the changes and act accordingly.
 
 the results of the changes and act accordingly.
 

-The main deficiency of DDT is that, although is names include the word 
-"dynamic", its operation is really static. The application program can 
-run freely, but when the programmer wants to see what is taking place, 
-the program must be stopped. Although the real interest may be about 
-changes on a gross scale, perhaps thousands of program statements, if 
-one does not know exactly where the program is misbehaving, one may be 
-required to suspend execution of it every few instructions to examine 
-variable in order to obtain a true picture of the program's behavior. 
-This the programmers see *not what is taking place*, but *what has 
-taken place*, and through small windows at that. This is inefficient, 
-and the programmer can become bogged down in detail that hinders the 
-discovery of the true problem. The situation can be improved with the 
-use of breakpoints that allow the program is execute freely until a 
-breakpoint is reached, at which point the program halts. DDT is a 
+The main deficiency of DDT is that, although is names include the word
+"dynamic", its operation is really static. The application program can
+run freely, but when the programmer wants to see what is taking place,
+the program must be stopped. Although the real interest may be about
+changes on a gross scale, perhaps thousands of program statements, if
+one does not know exactly where the program is misbehaving, one may be
+required to suspend execution of it every few instructions to examine
+variable in order to obtain a true picture of the program's behavior.
+This the programmers see *not what is taking place*, but *what has
+taken place*, and through small windows at that. This is inefficient,
+and the programmer can become bogged down in detail that hinders the
+discovery of the true problem. The situation can be improved with the
+use of breakpoints that allow the program is execute freely until a
+breakpoint is reached, at which point the program halts. DDT is a

 powerful tool but still leaves much to be desired in a debugging tool.
 
 powerful tool but still leaves much to be desired in a debugging tool.
 

-ESP (Execution Simulator and Presenter) is one solution to the static 
-problem. It really is dynamic is that large amounts of data are 
-constantly being displayed for the programmer while the program is 
-being executed (actually, simulated). The information is presented in 
-graphic form to improve readability and reduce confusion. A user of 
-ESP may watch areas of the display where data of particular interest 
-are being presented. One also has many options including control over 
-the speed of execution, the type of quantity of data displayed, and 
-special (more flexible than just a breakpoint) conditions for halting 
-execution. In this way one can structure and control the picture 
-presented to more easily understand what the simulated program is 
+ESP[^4][^5] (Execution Simulator and Presenter) is one solution to the
+static problem. It really is dynamic is that large amounts of data are
+constantly being displayed for the programmer while the program is
+being executed (actually, simulated). The information is presented in
+graphic form to improve readability and reduce confusion. A user of
+ESP may watch areas of the display where data of particular interest
+are being presented. One also has many options including control over
+the speed of execution, the type of quantity of data displayed, and
+special (more flexible than just a breakpoint) conditions for halting
+execution. In this way one can structure and control the picture
+presented to more easily understand what the simulated program is

 doing. And that is one key step in the process of debugging.
 
 doing. And that is one key step in the process of debugging.
 

-Like DDT, ESP has deficiencies also. These are mainly in the area of 
-editing and DDT-like examination of a faulty program. DDT is a 
-sophisticated language that ESP does not attempt to entirely replace. 
-The flaw in ESP is that it is not compatible with DDT. Ideally both 
-should be simultaneously available to the programmer, who can use 
+Like DDT, ESP has deficiencies also. These are mainly in the area of
+editing and DDT-like examination of a faulty program. DDT is a
+sophisticated language that ESP does not attempt to entirely replace.
+The flaw in ESP is that it is not compatible with DDT. Ideally both
+should be simultaneously available to the programmer, who can use

 features of each as the need dictates.
 
 features of each as the need dictates.
 

-DDT and ESP work with a low-level language whose operation can be 
-shown fairly simply. For example, ESP often shows flow of control by 
-just displaying the actual section of program being executed and 
-pointing to the current statement. It also draws lines to show where 
-branching has occurred and in some cases even indicates looping. The 
-display philosophy can be readily extended to higher level languages 
-that are line oriented, like BASIC, but it fails with applicative 
-ones, like LISP or Muddle. The latter type does not use a linear 
-control flow, but uses a complex depth-first tree structure. 
-Furthermore, quite complicated data structures can be built (or 
-themselves executed) that bear little relation to the appearance of 
+DDT and ESP work with a low-level language whose operation can be
+shown fairly simply. For example, ESP often shows flow of control by
+just displaying the actual section of program being executed and
+pointing to the current statement[^6]. It also draws lines to show
+where branching has occurred and in some cases even indicates looping.
+The display philosophy can be readily extended to higher level
+languages that are line oriented, like BASIC, but it fails with
+applicative ones, like LISP or Muddle. The latter type does not use a
+linear control flow, but uses a complex depth-first tree structure.
+Furthermore, quite complicated data structures can be built (or
+themselves executed) that bear little relation to the appearance of

 the program.
 
 the program.
 

-A good basic display for Muddle was used in MUMBLE (Gerald Farrell's 
-monitor and debugging aid). The code being executed is shown in stack 
-form. Each line shows a piece of code being evaluated. As each object 
-in the bottom line is evaluated, it is replaced by a single 
-downward-arrow symbol in this line and then printed on a new line. In 
-this way the evaluation can be followed from the top level down to the 
-current object being evaluated. Furthermore, after the bottom is 
-reached, the value returned by each line replaces its symbol in the 
-previous line. With this mechanism, the programmer can follow 
+A good basic display for Muddle was used in MUMBLE[^7] (Gerald
+Farrell's monitor and debugging aid). The code being executed is shown
+in stack form. Each line shows a piece of code being evaluated. As
+each object in the bottom line is evaluated, it is replaced by a
+single downward-arrow symbol in this line and then printed on a new
+line. In this way the evaluation can be followed from the top level
+down to the current object being evaluated. Furthermore, after the
+bottom is reached, the value returned by each line replaces its symbol
+in the previous line. With this mechanism, the programmer can follow

 execution in a natural and reasonably clear representation.
 
 execution in a natural and reasonably clear representation.
 

-MUMBLE had some difficulties arising from the fact that it simulated 
-execution rather than just watching it and letting it proceed 
-naturally. This caused it to run slowly and to be complex yet fragile. 
-At the time MUMBLE was written, the Muddle compiler was not yet 
-perfected and the language itself lacked some of the multiprocessing 
-features that would have made simulation unnecessary. Later Farrell 
-replaced MUMBLE with a debugger utilizing new software related to 
-single-stepping a process, which eliminated the simulation but also 
-eliminated the feature reflecting results of an evaluation back into 
-the original code. Also, a mode was added that allowed the programmer 
-to attach conditions to parts of the program which would stop 
-execution when and if a condition was false. This is as far as MUMBLE 
-ever progressed, and it was not in use as of the time of the proposal 
-for the current work.
\ No newline at end of file
+MUMBLE had some difficulties arising from the fact that it simulated
+execution rather than just watching it and letting it proceed
+naturally. This caused it to run slowly and to be complex yet fragile.
+At the time MUMBLE was written, the Muddle compiler was not yet
+perfected and the language itself lacked some of the multiprocessing
+features that would have made simulation unnecessary. Later Farrell
+replaced MUMBLE with a debugger utilizing new software related to
+single-stepping a process, which eliminated the simulation but also
+eliminated the feature reflecting results of an evaluation back into
+the original code. Also, a mode was added that allowed the programmer
+to attach conditions to parts of the program which would stop
+execution when and if a condition was false. This is as far as MUMBLE
+ever progressed, and it was not in use as of the time of the proposal
+for the current work.
+
+MEND
+----
+
+After the Muddle compiler became operational and many additional new
+software features became available, it appeared that it would be
+possible to design and implement a debugging system that would be
+comprehensive, easy to use, and reasonably fast. It was therefore
+proposed that a debugging system for Muddle called MEND (Muddle
+Executor , aNalyzer, and Debugger) be designed and implemented. It has
+the following characteristics. (A glossary of special terms, those in
+all capital letters, used here and throughout the rest of this memo
+may be found in Appendix B.)
+
+1.  MEND possesses a display similar to that of MUMBLE, including the
+    replacement of arguments in a FORM by their values as they are
+    evaluated.
+2.  Execution is monitored from another process (as opposed to being
+    simulated as in ESP) using 1STEP and related features[^8].
+3.  Execution speed is variable by the user including a static single
+    or multi-step mode where desired.
+4.  MEND allows execution to run freely below a certain depth of
+    evaluation or between certain points in the program and to run
+    controlled elsewhere.
+5.  Unconditional and conditional breakpoints are available that can
+    be attached to any object to halt execution before evaluation of
+    that object.
+6.  The system is capable of keeping track of programmer specified
+    conditions and of changing modes or giving some visible indication
+    when the conditions are met (or not met).
+7.  Information, such as the local value of programmer specified ATOMs
+    and the values of programer specified FORMs, is constantly
+    displayed beneath the main display.
+8.  Each line in the main display area is &-printed (abbreviated
+    printing, see glossary) and can be viewed in full at any time.
+9.  At any time, with execution stopped, the user can EVAL objects in
+    the ENVIRONMENT of the program. This means the user can examine
+    the state of the program or change it.
+
+Possible Additional Characteristics
+-----------------------------------
+
+Certain other characteristics were seen as desirable for MEND but
+possibly beyond the scope of this project. If time permitted these
+features were to be included in the system:
+
+1.  The IMLAC multi-screen capability would be used to allow the user
+    to rapidly switch between the debugger display and the program's
+    own output. Other system output could also be put on additional
+    pages.
+2.  The editor IMED (an editor for Muddle objects analogous to
+    IMEDIT[^9]) would be tied into the system to allow easy editing.
+    PRINTTYPE and READ-TABLEs would be used to allow breakpoints to be
+    easily set and removed in IMED as single symbols. Other control
+    codes and statements could also be inserted using this editor.
+3.  At the applications programmer's option and within certain limits,
+    execution could be reversed either so that something different
+    could be tried or for purposes of reexamining the process for
+    something that may have been missed the first time. This feature
+    could come in two possible forms, the UNDO package[^10] to
+    actually reverse execution or a simulation displaying information
+    previously stored by the system.
+
+Design and Implementation
+-------------------------
+
+MEND was designed with the intent of providing the application
+programmer with many options so that debugging could proceed in the
+most suitable manner for each situation. In the normal running state,
+MEND displays several kinds of information on the screen. Most
+important is an area showing the execution of the application program
+being debugged in stack form. The only other area that is always
+present is a line or two of status information about the current
+operation of MEND showing its current speed of execution (user
+adjustable) and the state of each modifiable mode.
+
+It was intended that the output of the application program be saved by
+MEND for later reference. The user of MEND could then elect to have
+the most recent output constantly displayed in a window on the main
+screen (see section on future work). If multi-screening were
+available, the output could be kept on another virtual screen. That
+screen could be displayed or made invisible at the user's option
+without stopping MEND.
+
+Information such as programmer specified values of ATOMs, structured
+objects, and, in general, the value of any Muddle expression may be
+constantly displayed. MEND is also capable of displaying such
+information on an exception basis according to some predescribed
+condition. Such information is &-printed but is viewable in full when
+desired.
+
+It is important for a debugging system like MEND to be compatible with
+and to take advantage of available software in related areas. One such
+area is editing. There were two Muddle editors in use when the
+proposal for this work was made, EDIT[^11] and IMED. The main
+difference between them is that IMED uses the local editing features
+of the IMLAC while EDIT does not. EDIT, however, has the advantage of
+being the only one that possesses breakpoint capabilities. Whichever
+proved to be most compatible with MEND (possibly both) would be
+slightly modified to allow the setting and removing of certain MEND
+codes including, in the case of IMED, breakpoints.
+
+Muddle itself has many features that greatly aid the debugging
+process. One of these is FRAMES. This function can be used to print
+the stack of functional evaluations and applications when execution is
+halted at any depth below the top level. At this point it is also
+possible to get the values of objects in the current ENVIRONMENT and
+to change them. One can even restart execution at a higher level after
+making such changes. Because the Muddle debugging features are quite
+powerful, MEND was designed to allow the user to stop execution (of
+the application program) and to use these aids or any others built in
+to Muddle with the MEND system itself transparent. Evaluation would
+take place in the ENVIRONMENT of the application program.
+
+MEND now includes the main features of all the debuggers that have
+been mentioned and enough other features that it should prove to be
+quit useful for the analysis and debugging of Muddle programs. It
+should also serve as a good example of the type of debugging system
+that can be built around an applicative type language.
+
+[^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer
+    Journal 1973, volume 7, number 3, pages 182-198
+
+[^2]: Digital Equipment Corporation, "DDT-10 Programmer's Reference
+    Manual", Assembly Language Handbook, DEC-10-NRZA-D
+
+[^3]: B. Bressler, DDT: A Debugging Aid, SYS.06.01, Programming
+    Technology Division Document, Laboratory for Computer Science,
+    M.I.T., November, 1971
+
+[^4]: S.W. Galley, Debugging with ESP -- Execution Simulator and
+    Presenter, SYS.09.01, Programming Technology Division Document,
+    Laboratory for Computer Science, M.I.T., November, 1971
+
+[^5]: S.W. Galley and R.P. Goldberg, "Software Debugging: The Virtual
+    Machine Approach", Proceedings of the Association for Computing
+    Machinery Annual Conference, November, 1974, volume 2, pages
+    395-401
+
+[^6]: M.H. Liu, DETAIL: A Graphical Debugging Tool, S.B. Thesis,
+    Department of Electrical Engineering, M.I.T., February, 1972
+
+[^7]: G.J. Farrell, A System for Muddle Programming, M.S. Thesis,
+    Department of Electrical Engineering, M.I.T., August, 1973
+
+[^8]: S.W. Galley and G. Pfister, Muddle Programming Language Primer
+    and Manual, Laboratory for Computer Science, M.I.T., May, 1977
+
+[^9]: J. Haverty, IMEDIT Editor Program for Use with the Imlac
+    Terminals, SYS.08.01.02, Programming Technology Division Document,
+    Laboratory for Computer Science, M.I.T., August, 1972
+
+[^10]: B. Berkowitz, UNDO, Undergraduate Research Report, Programming
+    Technology Division, Laboratory for Computer Science, M.I.T.,
+    December, 1974
+
+[^11]: N. Ryan, EDIT: The Muddle Editor, SYS.11.14, Programming
+    Technology Division Document, Laboratory for Computer Science,
+    M.I.T., August, 1974