[m-dev.] For review: new data structure for declarative debugging

Mark Anthony BROWN dougl at cs.mu.OZ.AU
Mon Nov 29 16:53:20 AEDT 1999


Hi,

Unless there are any objections soon, I'll go ahead and commit this.
Regarding the feature freeze:
	- the changes are to an isolated part of the system (the
	  declarative debugging back end, and some of the front end);
	- the "features" aren't really new, they replace existing
	  features which don't work properly.

Cheers,
Mark.

> 
> Hi,
> 
> This is the first installment of the new declarative debugger
> design.

...
> 
> Estimated hours taken: 160
> 
> Implement a new data structure for declarative debugging.  The
> major differences between this and the old implementation are:
> 	- The data structure is implemented in Mercury.  The definition
> 	  of the type, and procedures for constructing values of that
> 	  type, have been moved from trace/mercury_trace_declarative.{c,h}
> 	  to browser/declarative_execution.m (which is a new module).
> 	- The front end no longer needs to call the back end via an
> 	  indirect pointer---the front end does not call the back end at
> 	  all.
> 	- The data structure is not specifically for wrong answer
> 	  analysis, it is intended to be used for any sort of analysis.
> 	- The data structure represents execution at a lower level---the
> 	  new front end defines a more abstract view in terms of this
> 	  data structure.
> 
> Implement a test harness for debugging the front end code.  This allows
> the front end to run as a stand-alone program, which can then be
> debugged using `mdb'.
> 
> The code in the front end does not currently handle the new structure
> very nicely.  This is because that code is about to undergo some major
> structural changes, so there is little point cleaning it up now.
> Consequently:
> 	- Some of the code in the front end is incorrect (eg. the
> 	  user interface does not print missing answer nodes
> 	  properly).
> 	- The tests have not been reinstated.
> These things will be fixed in subsequent changes.
> 
> Likewise the compiler still reserves two stack slots, even though
> only one is required.  After this change the algorithm should be able
> to get away with using no stack slots, so modifications to the compiler
> will be postponed until then.
> 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list