set in this system. At least they are useful and no one has yet
suggested another type of breakpoint that would also prove useful.
+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.
+
[^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer
Journal 1973, volume 7, number 3, pages 182-198
projects / mudman.git / blobdiff