+V Final Thoughts about MEND
+===========================
+
+V.1 Monitoring of Values
+------------------------
+
+A feature that was originally considered to be important, and is
+present in ESP[^4][^5], is the constant monitoring of values. This
+feature has not been too happily received in MEND, but that may be
+due more to the current implementation than to an inherent lack of
+utility.
+
+Ideally one should not have to see the object being monitored or its
+value if one does not want to. The debugging system should be capable
+of performing certain actions upon, for example, a change in value.
+This would be analogous to conditional breakpoints except that the
+test would be performed after each step of execution of the
+application program rather than at certain arbitrary times.
+
+One problem with the above scheme is the difficulty of testing for a
+change in value (the basic test). For example, the value of an object
+being monitored may be some sort of structure. During execution the
+application program may not explicitly change the value of the object
+but may change an element of the structure that the object evaluates
+to. Assuming MEND had saved a pointer to the structure, if it now
+evaluated the object being monitored, it would again find that
+structure and assume that the value had not changed. However since an
+element of the structure had changed, the programmer would probably
+want to be notified.
+
+The only solution to the above dilemma is to at each step save a
+complete representation to all levels of the value of the object in
+some form that cannot be affected by the application program. This
+can be done by, at each step, unparsing the value to be saved for
+future tests into its printed (string) representation. Then the
+comparison of current and previous values will simply be a string
+comparison, not subject to sharing by the values. Unfortunately this
+may create incredible amounts of "garbage." In fact, a circular list
+(quite legal) will produce a string of infinite length!
+
+The solution finally chosen was to print the values of the objects
+being monitored at each step and to let the user visually compare
+versions. The values are &-printed as usual but may be examined in
+full at will.
+
+When tested it became immediately obvious that the constant
+reprinting wasted time and was distracting. A feature was added to
+cause printing to occur only at controllable intervals, but that
+produced other problems. Primarily the user might not see a change
+that had occurred at one step until some later step when valuable
+information had already been lost. One would also not have the
+opportunity to take immediate action.
+
+What needs to be done at this point is to reduce the emphasis on such
+pathological cases as described above. Printing should only occur at
+well defined moments (i.e., when requested or when some recognizable
+condition occurs). Only gross and easily testable changes in value
+should be watched for (i.e., the value is a new object, entirely).
+Conditional monitoring should be installed analogous to the
+conditions of breakpoints. With all of this testing, a variety of
+indications should be available as with breakpoints.
+
+V.2 Control Stack Display
+-------------------------
+
+MEND's display of the application program's control stack has proven
+to be by itself a highly useful debugging aid. This display can be
+and often is used without any of MEND's other features to debug a
+faulty program. It should also be emphasized that a valid use of this
+display is to monitor a working program in order to understand its
+operation. In this case, where the user of MEND is completely
+unfamiliar with the operation of the application program, MEND's
+step-by-step display of program execution is even more useful than in
+the normal debugging situation.
+
+One of the unique features of MEND's "trace" of the application
+program is that MEND shows both the code being executed and the
+results of that execution. Since Muddle is an applicative language,
+most of the results consist of values returned by evaluated objects.
+By reflecting the returned values back into the original code, MEND
+shows intermediate results in an intuitive manner for the user.
+
+Other programming languages could also benefit from this sort of
+display. Too often a trace routine provided for debugging in a
+language shows only results of execution, such as value assignments,
+without showing the corresponding program steps, or it shows program
+steps but leaves it to the programmer to insert instructions to show
+intermediate results. What the programmer really needs to see is a
+well-integrated display of both program instructions and results,
+such as MEND provides.
+
+Muddle is an exceptional language in that the MEND display was
+implemented fairly cleanly with just a package of Muddle functions
+and without changes to the interpreter itself. With suitable language
+enhancements, however, a similar display could be provided for LISP
+or any other LISP-like language. Although major compiler
+modifications would be required, a stack-oriented display might also
+be suitable for a block structured language like ALGOL.
+
+Especially in a block structured language, where instructions might
+be treated in groups rather than individually, but also in
+applicative languages, it would be useful to be shown variable
+bindings as they occur. Muddle does not provide any information about
+the occurrence of bindings, so the programmer is not informed of such
+occurrences by MEND. However when major modifications are made in a
+language to provide a display similar to MEND's, it would probably be
+a mistake not to include a provision for notifying the programmer of
+variable bindings and unbindings as they occur.
+
+V.3 Simulation Vs. Multiprocessing
+----------------------------------
+
+Besides its control stack display, MEND's other major feature, and
+its major difference from debugging systems like EEP or the first
+version of MUMBLE, is its use of multiprocessing rather than
+simulation to follow application program execution. (Even debugging
+aids that use multiprocessing often do not work the way MEND does.
+While MEND is a program written in the same language and running
+concurrently in the same interpreter as the application program, some
+debuggers , such a DDT, are machine language programs running near
+the application program, and others are simply complied into the
+language itself.) This feature is perhaps the key to MEND's success
+as a debugger. The choice to avoid simulation certainly reduced the
+size and complexity of MEND by two or three times and similarly
+affected run time. What remains to be discussed are the tradeoffs
+involved in the choice. The advantages just mentioned heavily favor
+the multiprocessing solution but there are other considerations.
+
+If MEND had been implemented using simulation, it would for the
+evaluation of each object determine which elements need evaluation;
+evaluate those elements by recursively calling MEND's own evaluation
+simulator; determine whether some function should be applied;
+determine the effects of the required functional application, if any;
+and cause those effects while displaying some representation of them
+for the programmer. In short, MEND would duplicate the actions of
+Muddle while maintaining and updating its own information about those
+actions. Therefore MEND would at all times know exactly what the
+application program was doing and could never miss some important
+effects of execution or be fooled by an unusual program. In the
+previous section it was stated that it is desirable to show the
+occurrence of variable bindings to the programmer. This feature would
+be easy to implement in a debugging system that simulated execution
+of the application program.
+
+But what about a debugging system using multiprocessing? A
+multiprocessing debugger, such as MEND, allow s the application
+program to execute more-or-less freely in its own process while
+monitoring it from another process. Since MEND id not in direct
+control of the application program, it must rely for its information
+on whatever data it is given by the multiprocessing mechanism built
+into Muddle and on inferences based on examination of the application
+program's environment, its knowledge of the general behavior of
+Muddle programs, and some specific knowledge of special cases. The
+occurrence of variable bindings is not decipherable from the
+information that MEND can gather. Fortunately, as has been previously
+shown, MEND does have the information essential to the creation of
+its display and the display is a sufficient debugging tool.
+
+Monitoring execution of the application program from another process
+provides sufficient information for a useful debugging system while
+simulation of the application program provides enough information for
+a more comprehensive system. Therefore if speed and size of the
+debugger were not important factors, then, although not a necessary
+choice, simulation would be the favored choice for a debugging system
+except for one other factor.
+
+The simulator needs much more knowledge of specific details of the
+behavior of program functions than does the monitor. In fact the
+simulator must know exactly the effects of each function that might
+be used in the application program. Uncompiled user-defined functions
+are no problem. They consist merely of one or more applications of
+other functions to given arguments. Complied user-defined functions
+cannot be dealt with at all without actually creating a simulator for
+machine language programs, a project comparable in magnitude to the
+design and implementation of all of the other parts of the simulator
+combined! The remaining functions are Muddle's built-in primitives.
+They are well defined but frequently change (usually upward
+compatibly). Furthermore new primitives are constantly being added. A
+simulator for Muddle programs would therefore quickly become
+outdated.
+
+Given the problems of a simulator and the relatively few drawbacks of
+a monitor, it is clear now why MEND was implemented as the latter.
+The same arguments apply to debugging systems for other languages.
+Whenever the appropriate multiprocessing features exist, with
+sufficient information available about execution in another process,
+a debugging system based upon simulation of the application program
+should be rejected in favor of a monitor-type system. MEND has proven
+to be an effective debugging aid and should serve as a good example
+of the latter type of system.
+
+VI Suggestions for Future Work
+==============================
+
+VI.1 Monitoring of Access
+-------------------------
+
+Because of the problems described in Section V.1 concerning the
+monitoring of values, there was not enough time to work on a related
+but more interesting feature for MEND. Frequently the main piece of
+information that is available about a bug Ii a program is that at
+some point a certain data area (variable value, list slot, etc.) is
+being "clobbered" by function(s) unknown.
+
+Rather than watching the program execution in detail to find the
+culprit, it would be far more useful to set a break point on access
+to the location in question. This could be done by having MEND
+redefine all data access functions to watch for certain locations.
+Not only would that be messy, but it goes against one of the basic
+philosophies of MEND. With good reason, as described earlier, MEND
+tries to alter its environment as little as possible. (For example,
+what if the application program redefined one of the functions also?)
+
+Muddle again provides the answer. The code already exists for
+monitoring read or write access to any standard data location. It is
+only necessary to set up the proper type of interrupt handler with a
+pointer to the location to be watched. Each time the specified type
+of access occur, the handier will be called with all of the
+particulars.
+
+MEND should have commands installed for creating and destroying such
+handlers. For consistency and to facilitate remembering for the user,
+the possible actions of this handler upon being called should be
+similar to those of breakpoints and of monitoring of values.
+
+VI.2 Other Unimplemented Features
+---------------------------------
+
+Three other proposed features were not implemented due to an acquired
+belief that the value of each of these features in relation to the
+goals of this work was not worth the time required to properly
+implement it. However each of these features has merit and may be
+desirable in some future, more comprehensive debugging system.
+
+The first such feature involves saving all output of the application
+program for the programmer to refer back to. This has the
+implementation difficulty that there is no easy way to separate
+application program output from much of the MEND output. All
+application program output and certain MEND output goes to the lower
+section of the screen utilizing the same output mechanism (i.e.,
+standard Muddle output to the primary terminal output channel). No
+distinction is made between the two kinds of output. A distinction
+could be made, by having MEND do all of its output through yet
+another terminal output channel (a second channel is currently used
+for the upper screen section), but another consideration made the
+effort seem not worthwhile. In practice, programs that produce a lot
+of output usually send it to a file and not to the terminal. Since
+only small amounts of output are usually sent to the terminal, a
+short output history, such as that which is present on the screen
+itself, is generally sufficient.
+
+The second unimplemented feature would have allowed the setting of
+MEND breakpoints using the editor IMED. This would have meant sending
+a function out to the IMLAC where, local editing would have been used
+to create, or delete such breakpoints. PRINTTYPE and READ-TABLEs
+would have been used to allow for setting normal breakpoints and the
+special MEND types (ON, OFF, etc.) using one or two mnemonic
+characters.
+
+The primary reason that this feature was not implemented was that
+EDIT wad chosen to be the MEND editor instead of IMED. That choice
+was made partly because EDIT is in many respects the more powerful of
+the two, but mostly because EDIT is the editor now used almost
+exclusively by Muddle programmers. In fact, EDIT is now pre-loaded in
+Muddle while IMED is not. Another reason for rejection of this
+feature was that it would have made MEND, or at least this part of
+it, terminal dependent.
+
+In a different environment a similar feature might be quite useful.
+IMED still has the large advantage over EDIT that by constantly
+displaying the entire function while the programmer moves the cursor
+around in it, creating and deleting MEND "command symbols" at will,
+the user is provided with a much better feel for the debugging
+environment being set up than with EDIT.
+
+The third feature would allow the user to reverse execution of the
+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
+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
+Muddle Itself, and even UNDO is not foolproof.
+
+The only practical way this feature could be implemented is in its
+second variety. It would be possible to store (in a file, probably)
+information specifying the state of the MSTACK (at each step and to
+allow the programmer to view previous steps in some comfortable
+manner. The time required to implement this feature, though, put it
+outside the scope of this work.
+
+VI.3 Immediate Action Commands
+------------------------------
+
+Empirical evidence suggests that one more interrupt -level immediate
+action command would be highly useful. Currently the user may skip
+over the complete execution of a single object by typing ↑O just
+after the object is placed on the stack for evaluation. The user may
+also want to rapidly complete the evaluation of some object that is
+already executing. For example, one may have watched the first few
+objects in a REPEAT loop being evaluated and now wants to free-run
+the application program until the looping is finished. For such a
+case, a command should be available to skip over the evaluation of
+the current object and all others at the same level (i.e., finish
+evaluation of the object on the previous level).
+
+Further use of MEND may indicate a need for other interrupt-level
+commands. (Perhaps certain interrupt-level commands should somehow be
+able to take arguments?)
+
+VI.4 Terminal Handling
+----------------------
+
+The MSC implementation of MEND was discarded because of problems
+specific to the current operating environment. In a suitable
+environment, multi-screening is still seen to be a useful feature for
+a similar debugging system. It has even been suggested that something
+of the sort could be implemented using two separate terminals. One
+terminal would look to the application program just like the terminal
+it would have seen in the absence of MEND. The other terminal would
+be used for communications with MEND. Not only would this eliminate
+output conflicts between the application program and MEND, but with
+two keyboards there would be no need to have a reserved character set
+for MEND interrupt -level commands. Of course, it might be difficult
+for the user of such a system to coordinate activities between the
+two terminals.
+
+Another area where MEND might be improved is its knowledge of the
+terminal being used. As has been previously discussed, it currently
+assumes certain basic display functions and relies upon ITS to
+understand the requirements of the terminal. Although ITS handles the
+job well, it is not the only operating system that Muddle may run
+under. This author, in fact, actively uses Muddle under TENEX, an
+operating system that lacks the terminal code to support MEND. To
+properly work under most operating systems, MEND would have to be
+tailorable to individual terminal codes and requirements and would
+have to do much more of the work than under ITS.
+
+It has been proposed that MEND could be made to work in some fashion
+with the basic ASCII printing terminal, something that nearly all
+terminals and operating systems can simulate. However it is the
+opinion of this author that MEND would lose much of its value under
+such conditions. Watching the stack grow and shrink, and seeing
+objects replaced by their values, gives the user more of a feel for
+what the application program is doing than a long stream of
+sequentially printed lines ever could.
+
+Appendix B: Glossary of Terms
+=============================
+
+&: A function pre-loaded in Muddle that prints objects in an
+abbreviated form to fit in a programmer-specified number of character
+positions.
+
+1STEP: A built-in Muddle function used by one program to single-step
+another for debugging purposes.
+
+ATOM: A Muddle variable.
+
+COND: A built-in Muddle function providing a general conditional
+capability. The arguments to CONO are lists. Muddle evaluates the
+first element of each list in turn until an element returns a
+non-false value. Then the rest of the elements in the current list
+are evaluated and COND returns what the last element in the list
+returns.
+
+DDT: A program used to debug assembly language programs.
+
+DEBUGR: A program utilizing Muddle's single-stepping functions to
+show a programmer the step-by-step execution of a program. DEBUGR is
+an attempt to provide a DDT-like debugger for Muddle programs.
+
+EDIT: A pre-loaded editor for Muddle objects. EDIT works within
+Muddle by restructuring the object being EDITed according to the
+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.
+