Morphine is an extensible debugging environment for Mercury [7,8] which offers support for high-level debugging strategies. A broad scope of Mercury programmers ranging from beginners to experienced Mercury users should find accurate debugging support in Morphine. This introduction lists potential users of Morphine and briefly describe its basic features.
Morphine is an adaptation to Mercury of the Opium debugger which was designed for Prolog. A number of articles describe in detail the principles of Opium, see in particular [2,4] 2. An adaptation of Opium to C called coca is described in [3].
If you think that simply stepping through execution traces is all you need, you should still try Morphine because with a handful of commands plus Prolog you can specify easily the very trace line(s) you want to see. Start with Section 3 which explains the minimum you need to know in order to run Morphine.
If your program has huge data structures and you would like to have them abstracted with several levels of abstractions, Morphine has powerful general mechanisms to do this. Furthermore, it will help you program dedicated display procedures and integrate them in the environment.
If you have always been complaining that tracers were not powerful enough and longing for a debugger that will enable you to write powerful macros, then Morphine should have all that you could wish for. It is not only macros but real debugging programs that you can easily write. Section 5 explains how to tailor the debugging environment to your taste and needs.
If you are writing an application which in turn requires some debugging facilities, then Morphine should be a great help. You can provide your users with tracing and debugging facilities at the proper level of abstraction without touching your source code! Section 6 tells you how to extend Morphine.
In this section, each of the following features is detailed in turn. Morphine is fully programmable and the programmed commands are grouped into ``scenarios''. The environment is extensible and customizable. Morphine is running in coprocessing with the debugged session.
Tracers usually print the information they retrieve. By contrast, Morphine handles the debugging information as programming data. The debugging information (trace and source) can then be analysed by programs before it is printed.
Some tracers provide ``macros'', Morphine offers a full programming language to implement debugging commands and programs. Morphine's language is Prolog extended by a set of debugging primitives. Backtracking and unification enable the user to write concise and powerful commands on the fly.
Tracers usually provide a flat set of commands. In Morphine, the set of debugging commands is structured into scenarios. Each scenario corresponds to a certain debugging strategy, or to a certain aspect of debugging. For example, there is a scenario for examining the traced execution step-by-step, and there is a scenario supporting the user on examining the source code. Hence learning Morphine and navigating through it is relatively easy although the number of (interesting) functionalities is high. The scenario structure is only a ``virtual'' structure to help people use Morphine. Any command visible from the current module can be executed at any time. The scenario paradigm is also the basis of the customization and extensibility mechanisms (see sections 5 and 6).
Thanks to Prolog, new predicates can be easily added and directly used as commands. Furthermore, existing commands can be customized without knowing the details of their implementation. They can also be reset to their default values. New scenarios can be added. With a minimum of declarations, Morphine ensures that the new scenario is integrated into the system. Interface, help, manual, and some consistency checking will be added automatically (see sections 5 and 6).