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.
+1. The IMLAC (see section II.1) 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
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.
+
+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.
+
[^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer
Journal 1973, volume 7, number 3, pages 182-198
projects / mudman.git / blobdiff