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 / commitdiff