+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.
+
+Terminal Display
+================
+
+IMLAC Console Program
+---------------------
+
+One basic concern throughout the project was the display: how the
+information made available by MEND would be presented to the user. To
+a large extent the physical characteristics of Muddle, ITS[^12]
+(Incompatible Timesharing System, the operating system used on the
+Dynamic Modeling System computer), and the available terminals
+dictated what was reasonably possible.
+
+The terminal most commonly used by users of the Dynamic Modeling
+System is the IMLAC PDS-1. This is a minicomputer capable of having
+programs loaded into it from the PDP-10 host computer. One program
+written for it by Dave Lebling is MSC, a multiple-screen terminal
+program. Up to four virtual screens (or pages) can be created that
+will individually operate like the actual screen area of the standard
+terminal program (SSV\[\^13). Output may be directed to any one of the
+screens and any screen may be visible or invisible at any instant of
+time, at the programmer's option. Selection of screen is controllable
+either by program from the host or locally by the user.
+
+It was originally Intended that MEND would use MSC for its normal
+display. One page would constantly show MEND's representation of the
+control stack of the application program. Output initiated by the
+program being debugged would go to a second page. A third page would
+be used for interaction with MEND and would show user typein along
+with any output from MEND that one was interested in seeing. The
+latter would include, by user request, full displays of both objects
+printed in an abbreviated form on the page containing the control
+stack of the application program and values being monitored or traced.
+The user could switch back and forth among the pages at will during
+the execution of the program. The application program would have a
+full standard screen to write onto, and ample room would be available
+for the information to be displayed by MEND.
+
+After a fair amount of testing, this proposal was discarded for the
+following reasons. First, MSC was supposed to look just like SSV for
+individual virtual screens. Unfortunately new features added to SSV
+had not also been added to MSC. A primary reason for this disparity
+was that the new features encroached upon the IMLAC's character space.
+An SSV with all current features can only hold about one and a half
+full pages of text, where a page is the amount that can be visible at
+one time. The overhead required for additional screens reduces it
+still further. Therefore, with all features included, four virtual
+screens could each only average about one-third full. Without many of
+the current features, people were reluctant to use MSC.
+
+The second and perhaps most devastating problem with MSC is that it is
+not properly supported by ITS as is SSV. Ordinarily the operating
+system will keep track of where on the page the terminal's cursor is
+and will properly handle such updating as deletions even in the face
+of random access performed (if done by request to the system). When
+using MSC, ITS does not realize that information is being written onto
+more than one screen and will therefore often move the cursor to the
+wrong position.
+
+MEND could completely control positioning for typeout and echoing on
+typein but that would add the large overhead of having to run a
+non-trivial routine for each character typed out on the display. Also,
+because MSC is not the standard console program, requiring the user to
+load it before using MEND might discourage the use of MEND. (It takes
+between about 30 seconds and a couple of minutes, depending upon
+system load, to load a new console program into the IMLAC.)
+
+From the outset it was intended that MEND be used routinely by
+programmers as debugging problems arose. Therefore it was decided that
+the proper way for such a system to operate was to use, as far as
+possible, the common environment so as to keep the overhead for
+invoking MEND small. This philosophy, which had been seen to affect
+the success of many earlier projects, decided between the alternatives
+and in this case led to the final decision to use SSV instead of MSC.
+
+Terminal Independence
+---------------------
+
+The MEND terminal handling capabilities are actually quite general and
+MEND does not depend exclusively on SSV. For the purpose of dividing
+the screen area into several sections, horizontal lines are sometimes
+drawn (see Appendix A showing sample display). With an IMLAC and SSV
+these lines could be drawn quite simply using graphics mode. However,
+for purposes of generality with regard to terminals, these lines are
+instead formed by using underbar characters (on a line of their own).
+By using no actual graphics MEND can be used with almost any display
+terminal having random access. MEND outputs display commands, such as
+clearing a line, as escape codes to ITS which then translates these
+into the appropriate commands for the terminal in use. ITS currently
+knows about several types of display terminals in use at the
+Laboratory for Computer Science, and other types of terminals located
+at foreign sites on the ARPA network may be handled by interface
+software that simulates a known type. Naturally MEND can handle a
+large range of possible line and screen lengths. (The current version
+of SSV provides four possible character sizes.)
+
+Control of Screen Sectioning
+----------------------------
+
+There still remained the question of how to handle the
+multi-sectioning of the displayed information. Originally three
+sections corresponding to the three virtual screens in the aborted MSC
+implementation were planned. The bottom section would hold user typein
+and application program output. Three possible methods of achieving
+this involved having ITS, Muddle, or MEND do various amounts of the
+work with increasing overhead and decreasing speed for those three,
+respectively.
+
+The most attractive solution utilized an ITS feature allowing the
+specification of an echo area at the bottom of the screen where echoed
+input would always be printed (with the echoing handled by the system,
+which is the normal case) . After some experimentation this method of
+handling the typein and application program output was rejected
+because typeout and deletion are handled by Muddle which ignores the
+echo area MEND would effectively have had to control all typeout and
+monitor all typein, which would have made the echo area useless.
+
+Experimentation with the second solution, an indirect method, involved
+monitoring of special Muddle memory locations where information
+concerning horizontal and vertical page positions is stored. It was
+soon discovered that Muddle becomes confused quickly, contains several
+bugs with respect to this position information, and generally has a
+poor idea of where it is actually printing.
+
+The third solution appeared to be the most painful from an
+implementation and efficiency point of view. MEND would need to
+control the printing of every character on output and certain
+characters on input, constantly checking page positions by querying
+the system. Not only did this slow output, but also MEND was forced to
+constantly move the cursor to a safe position in case Muddle managed
+to sneak some output past it, which it occasionally does.
+
+Fortuitously the problem was neatly solved when a little known feature
+of ITS was discovered. It Is possible to open a channel to the
+terminal in a mode that would cause all output to appear in the echo
+area. By creating this echo area and reopening Muddle's normal
+terminal output channel in this mode, it is possible to cause Muddle
+and the application program to think that the entire screen consists
+of only the echo area. All output including application program
+display escape commands is automatically routed by ITS to this echo
+area. MEND sends its output to a second channel opened in the normal
+mode, thereby allowing it to use an area of the screen unknown to and
+left untouched by the application program. The physical cursor stays
+where the last used logical cursor left it, thereby eliminating most
+of the unnecessary cursor movement, resulting in a more pleasing
+visual effect.
+
+As a result of this solution, the screen is divided into only two main
+sections. All typein appears in the lower section, whether it is to
+the application program or to MEND. Application program output also
+goes to the lower section, as does unstructured output produced by
+interaction with MEND. The upper section, in general, contains only
+those items that occupy one line of the display each. As will be
+explained later, these items include all output automatically
+displayed by MEND during execution of the application program.
+
+[^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
+
+[^12]: D. Eastlake, R. Greenblatt, J. Holloway, T. Knight, and S.
+ Nelson, ITS 1.5 Reference Manual, Memo No. 161A, Artificial
+ Intelligence Laboratory, M.I.T., July 1969