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

[Peter Schachte]

On Wed, 3 Jun 1998, Fergus Henderson wrote:

[Re: the distinction between spy and break points]

> > The distinction might make a lot of sense internally, but from the user's
> > point of view I think it would be simpler to think of them as the same
> > thing.  
> 
> I think you have it backwards.
> 
> I think there are (at least) two important groups of users to take into
> account:
> 
> 	(a) users that have used Prolog debuggers
> 	(b) users that have used imperative language debuggers
> 
> For those in group (a), the concept of "spy points" that stop at any
> port will already be familiar.  For those in group (b), the concept
> of "break points" that just stop at a particular place in the program
> will already be familiar.  So yes, spy point versus break point
> is just one of quite a few orthogonal dimensions in which the
> properties of a spy/break point can vary.  But because of the
> historical background I think the distinction between the two
> is important.  It's useful to give a name to the two different
> concepts.

But I'm not so sure that break points correspond very closely to break
points in imperative language debuggers.  In an imperative language, you
usually put a breakpoint on a line of code, and usually on any line that has
generated code associated, even just arithmetic calculations.  Instead, a
Mercury break point is placed on a place in the code based on a structural
description which will be difficult for a novice to understand.  And
imperative language debuggers allow you to put a break point on a procedure,
but the Mercury debugger won't (it'll have to be a spy point).

For the underlying command set, I think you would be much better off with a
single uniform concept of spy/break points.  Then make lots of nifty aliases
for users with different backgrounds if you like, or even have a
few different standard alias sets for users familiar with different
debuggers.

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?  The
latter would seem to be pretty easy, since you keep the line number around,
at least for a while, during compilation.  If you just emit some sort of
table for each file, or something like that, I would think you could allow a
more straightforward way of specifying a break point.


-Peter Schachte               | The fantastic advances in the field of
mailto:pets at cs.mu.OZ.AU       | communication constitute a grave danger to
http://www.cs.mu.oz.au/~pets/ | the privacy of the individual.
PGP: finger pets at 128.250.37.3 |     -- Earl Warren