[m-dev.] proposed command set for the internal trace based debugger

[Mireille Ducasse]

>> While on the subject, I have another comment.  It would be much more
>> comfortable for users to be able to refer to a particular place in the code
>> in a more lexical way.  For the Quintus debugger we used the calling
>> predicate, the called predicate, the clause number, and the ordinal number
>> of the call in that clause.  Another alternative would be line number in the
>> source file.  Would it be very hard for you to support one of these? 


As most of the previous discussion, I think this is something that
should be left to Opium.


What we want is

	- a tracer that provides as much basic information as possible
that can be provided AT LOW COST (in terms of the execution time).

	- a trace analyser that works on the basic trace. This
analyser can reconstruct part of the information as it has access to
the source code information (and to the operational model of Mercury).
Reconstructions being processed only upon explict request of the user
can be slightly costly.

The line number is a good example of what the trace analyser can deal
with without the basic tracer being involved.

Another good example is unification. You cannot afford to change the
unification procedure of the run time system. Most of the time the
user does not even needed any information about the unification
anyway. What is very easy to do in Opium is to simulate A PARTICULAR
unification. The program is very easy to write in Prolog, and the
performance is not an issue.