[m-rev.] Re: [m-dev.] for review: term dependencies in the declarative debugger

[Mark Anthony BROWN]

I'll commit this one on the main branch now, so I can continue work on
this section of code.  I'll address any further review comments after
committing.

Mark.

Mark Anthony BROWN writes:
> 
> Estimated hours taken: 40
> 
> This is the second part of a change to support term dependency analysis
> in the declarative debugger.  A `mark' command is implemented for the
> term browser, which allows a particular subterm to be selected and
> returned from the browser.  The declarative debugger interprets this as
> a suspicious subterm, and tries to find a child or sibling node from which
> this subterm comes.  This is used to determine the next question to be
> asked of the oracle.
> 
> browser/browse.m:
> 	Update the browser interface to allow for marked subterms being
> 	returned from the browser.
> 
> 	Implement and document the mark command.
> 
> 	Rewrite run_command as a switch instead of a chain of if-then-elses.
> 	This forces all unimplemented commands to be explicitly listed,
> 	and gives better error checking.
> 
> browser/browser_info.m:
> 	Add a maybe_mark field to the browser_info.  It is initially `no',
> 	but is updated when the mark command is given.
> 
> browser/declarative_analyser.m:
> 	Select which child or sibling node to ask about next by searching
> 	for the origin of the suspicious subterm.  If the subterm has mode
> 	`out' we act as if the oracle had answered no, and if the subterm
> 	has mode `in' we act as if the oracle had answered yes.  In future
> 	we may not wish to presume this -- we do so now mainly to keep the
> 	analysis algorithm simpler.
> 
> browser/declarative_debugger.m:
> 	Add a functor for suspicious subterms to the decl_answer type.
> 
> browser/declarative_oracle.m:
> 	Accommodate the changed answer type.  The oracle does not try to
> 	store information about suspicious subterms in the knowledge base,
> 	because in principle this could lead to infinite loops (although
> 	currently this wouldn't be a problem since we don't ever use the
> 	information to move upward in the tree, so no cycle could be
> 	formed).
> 
> browser/declarative_user.m:
> 	Accommodate the changed answer type, and interpret marked terms
> 	from the browser as suspicious subterms.
> 
> browser/parse.m:
> 	Add the new command.
> 
> browser/program_representation.m:
> 	Add a procedure to convert the browser's list(dir) to a term_path.
> 
> 	Change atomic_goal_rep_is_call/2 so it fails for special predicates,
> 	which was originally intended.
> 
> trace/mercury_trace_browse.c:
> 	Ignore the extra argument -- marked terms are not currently used in
> 	the main debugger.
> 
> tests/debugger/declarative/Mmakefile:
> tests/debugger/declarative/input_term_dep.*:
> tests/debugger/declarative/output_term_dep.*:
> tests/debugger/declarative/special_term_dep.*:
> 	New test cases.
> 
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------