Estimated hours taken: 40
Branches: main
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.
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.
Estimated hours taken: 0.75
Fix a bug which prevented bootstrapping in MLDS grades.
browser/program_representation.m:
Export to C a function ML_goal_rep_type() which returns the
type_info for a goal_rep.
trace/mercury_trace_internal.c:
Use ML_goal_rep_type(), rather than hard-coding the mangled
name for the type_ctor_info. (The hard-coded mangled name
was wrong for MLDS grades.)
Estimated hours taken: 20
Make procedure bodies available to the declarative debugger.
browser/program_representation.m:
Add _rep suffixes to the function symbols, to make iit easier to
distinguish HLDS goals and goal representations.
compiler/static_layout.m:
If --trace-decl is specified, include a representation of the procedure
body in the procedure's layout structure.
compiler/prog_rep.m:
A new module, containing the code that converts goals from HLDS
to a term in the format we want to put in the layout structure.
compiler/static_term.m:
A new module, containing the code that converts Mercury terms
to the LLDS rval we need to give to llds_out.m.
compiler/code_gen.m:
compiler/continuation_info.m:
Preserve the information needed by prog_rep
compiler/Mmakefile:
Extend the search path to the browser directory, since the new file
prog_rep.m imports one of the submodules of mdb.m stored there.
compiler/notes/compiler_desigm.html:
Document the new modules.
library/std_util.m:
Add a mechanism for static_term.m to use in converting terms into
rvals. This mechanism uses RTTI information to deconstruct terms,
and return not only their arguments, but also information about how
the term can be constructed from its arguments.
runtime/mercury_type_info.h:
Add a couple of macros to make construction and deconstruction of univs
easier, for use in std_util.m.
trace/mercury_trace_internal.c:
Add a new command, "proc_body", that prints out the representation
of the body of the current procedure. This is meant only for developers
to use to check that the procedure body representation is OK; it is
deliberately not documented.
Also fix a bug: make sure that we do not pass a NULL pointer to fputs
when echoing a line of input that isn't there (because we got EOF).
Estimated hours taken: 2
browser/program_representation.m:
New file to hold the definition of the representation of procedure
bodies to be used by the declarative debugger. This is committed now
so that Mark can write code to use this data structure while I write
code to generate it.
browser/mdb.m:
Mention the new module.
