[m-dev.] add goal path at external ports

[Fergus Henderson]

On 29-Jan-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Thu, Jan 28, 1999 at 09:40:46PM +1100, Fergus Henderson wrote:
> > > Fergus Henderson writes:
> > > > The compiler should generate line numbers in the debug info
> > > > (specifically, in the MR_Stack_Layout_Entry_Struct).
> > 
> > For each event, it would give the current line number at the time of that
> > event.  For call events, for example, that would be the line number
> > of the called procedure.
> 
> I would argue that the current line number at the time of a call is
> in the body of the *calling* procedure.

Well, I'd say that's a terminology issue.  I'm talking about things
at the implementation level here.  Each event is associated with
a particular procedure, and the "current line" for that event
should be a line in that procedure.  In the current implementation,
"call" events occur in the called procedure, not in the caller,
so the line number must be one associated with the callee.

We could in theory define some new event types, called say "before-call", 
"after-exit", "before-redo", and "after-fail", which would occur 
in the caller rather than in the callee.  (It would even be possible 
to rename the existing call/exit/redo/fail events to something different
and rename the new before-call/after-exit/before-redo/after-fail
events as call/exit/redo/fail, but that would be a shift in terminology.)
However, doing so would be quite inefficient.

It would certainly be possible for a source-linked debugger to
use source location from the immediate ancestor for external events
such as call/exit/redo/fail, and this would be more efficient
than introducing new events.

> > However, the stack tracing code gives you the ability to find
> > out the MR_Stack_Layout_Entry_Struct for each of your ancestors.
> > That would give you the line number for the caller.
> 
> Ok, as long as you can *always* get the right caller.

Right.

> But what about
> funny cases, like invocations of user-defined unification or invoking
> predicates through a type class.  How about invoking user-defined
> unification polymorphically (e.g. calling append(in,in,in) on three
> lists of sets-represented-as-lists-with-user-defined-unification)?

I think all of those kinds of things should work fine.

More difficult is if you stop at a call event (because you have
debugging enabled for the callee) and it turns out that you don't have
stack tracing enabled for the caller.

> Also, this might be a good time to remind you that just a line number
> isn't really good enough.

Well, for many purposes it is indeed good enough,
but I would certainly agree that it's not ideal.
I'd be happy to accept patches to fix this!

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.