At 03:11 PM 5/2/2001 -0700, Dave Storrs wrote:
>On Tue, 1 May 2001, Dan Sugalski wrote:
>
> > Right. What I'm thinking would be a good place to get to is a list of the
> > functionality that the debugger needs to provide or have available to it
> > from the interpreter, rather than the actual interface to the user. (Which
> > is important, but a separate issue)
>[snip]
> > though. I think we're still at the "What functionality should the
> > interpreter/compiler/parser provide to the person writing a debugger"
> phase.
>
>
> Errrmmm...sorry, but let me just be clear on this. I had intended
>to write this document in (more or less) the following sections:
>
> - things that the user can do (set breakpoints, step, etc)
>
> - implementation details of each feature in the previous section
>(what data structures do we use to store breakpoints? what information is
>associated with them? etc)
>
> - the internals of the debugger; its APIs, etc.
>
>
> It sounds like you don't want the first two sections.
s/\./ yet./;
>Can you
>give me a better idea of what exactly you are looking for in this
>document?
I see I wasn't in the least bit clear. Sorry. :(
What I want is a document that essentially declares "We want these things
available to the debugger to present to the user". The primary use for this
document is to make sure that we design in access points to the parser,
compiler, optimizer, and interpreter so that the debugger can get access to
the information that it needs and have the control one would usually like
from a debugger.
It's OK for this document to evolve into documentation of the debugger
itself (though that could also be reasonably considered a separate thing),
that's not what I was looking to shoot for yet.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
