[m-dev.] for review: term dependencies in the declarative debugger (first part)

[Mark Anthony BROWN]

I'll commit this soon, and deal with any review comments later.  I doubt
it will cause any problems, since the new code is not actually called yet.

This will be committed on the main branch only.

Cheers,
Mark.

Mark Anthony BROWN writes:
> 
> Estimated hours taken: 80
> 
> This is the first part of a change to support term dependency analysis
> in the declarative debugger.  A method is added to the mercury_edt
> typeclass which finds the origin of a selected subterm in an EDT node,
> somewhere in the body of the call or in the body of the parent.  The
> other parts of the change required before this can be useful are to
> modify the search strategy (in browser/declarative_analyser.m) to make
> use of the new information, and to modify the user interface to allow
> a subterm to be selected.  They will be committed as separate changes.
> 
> The typeclass method first traverses one or more contours, matching the
> contour events up with goals in a procedure representation.  This matching
> process requires a left to right traversal, because we need to know which
> disjunct/arm/branch was taken before we can match subgoals, and the
> DISJ/SWTCH/THEN/ELSE events which tell us this information occur at the
> left edge of the subgoals to which they apply.  But we must always start
> from the right hand side of the contour being traversed, so this means
> that a right to left traversal is required before the matching can start.
> 
> Using the contour matched up with the atomic goals, we track the location
> of a subterm by looking at which variables are bound, while scanning right
> to left along the contour.  Because this must happen after the matching,
> this must be a separate right to left traversal than the earlier one.
> Therefore the algorithm implemented here requires two passes over the
> contours in order to find the origin of the selected subterm.
> 
> browser/declarative_execution.m:
> 	Add a maybe(goal_rep) to call nodes in the annotated trace.  This
> 	is `no' if the relevant module was compiled below trace level `rep'.
> 
> trace/mercury_trace_declarative.c:
> 	If the information is available, fill in the goal_rep when
> 	constructing call nodes.
> 
> browser/declarative_analyser.m:
> 	Add the new method to the mercury_edt typeclass.
> 
> browser/declarative_debugger.m:
> 	Implement the new method.  Update for the changed call nodes.
> 
> browser/program_representation.m:
> 	Add a version of goal_paths to be used by the declarative debugger,
> 	and a predicate to parse these from goal_path_strings.  Add the
> 	types arg_pos and term_path to represent a subterm of a call or exit.
> 
> browser/program_representation.m:
> compiler/prog_rep.m:
> 	No longer store conjunctions in reverse order in the goal_rep; we now
> 	store them in the same order as in the HLDS.
> 
> 	Although we search conjunctions in reverse order, we need to match
> 	them up with contour events before doing that.  This can only be
> 	done in the forwards direction, so it turns out that there is no
> 	advantage in storing them in reverse order.
> 
> compiler/hlds_goal.m:
> compiler/trace.m:
> 	Add comments to the existing definitions of goal_path and
> 	path_step_to_string.
> 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------