[m-rev.] for review: dependency tracking

[Mark Brown]

A few preliminary remarks ...

On 19-Apr-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> For review by Mark.
> 
> Zoltan.
> 
> Redesign the way the declarative debugger traces dependencies, to avoid bugs

I call it dependency "tracking".  You sometimes call it "tracing" and
sometimes "tracking".  I'd stick with the latter, because it is quite
different to what we normally mean by tracing.  (I realise that my code
has a trace_dependency predicate, but this is referring to the fact that
it tracks dependencies in an annotated trace, as opposed to an EDT.  In
other words, this occurrence is the noun "trace", not the verb.)

> and make the code comprehensible. This required tacking an issue we could

s/tacking/tackling/

> ignore before: the typeinfos added to procedure arguments by the compiler.
> 
> browsers/declarative_debugger.m:
> 	Rewrite the dependency algorithm from scratch. It now has three phases:
> 	materializing the contour leading up to the relevent point in the
> 	procedure body, using that contour to construct a list of the conjoined
> 	primitive operations executed up to that point by the procedure body,
> 	and tracing the source of the marked subterm in this list of
> 	primitives.
> 
> 	Add a mechanism to print out the result of the dependency tracing
> 	algorithm if a flag is set, for testing and debugging.
> 
> browsers/declarative_analyser.m:
> 	Transmit the result of the trace dependency algorithm to where it may
> 	be printed out.
> 
> 	Be more consistent in the names of type variables.

I disagree with this part of the change, and I think you should undo it.
The names were following a consistent pattern: the type variables
constrained by the typeclass mercury_edt/2 were always named S and T, and
the type variables constrained by the typeclass annotated_trace/2 (which is
a lower level representation of the same data) were always named S and R.
The reason S appears twice is that it is essentially the same type,
although the wrap/1 type is used to get around restrictions on instance
declarations.

> 
> browsers/declarative_user.m:
> 	Update the user interface to make it switchable between viewing atoms
> 	from the user's perspective (with compiler-generated arguments hidden)
> 	and the implementor's perspective (with compiler-generated arguments
> 	visible). The default view is the user view.
> 
> browsers/declarative_execution.m:
> 	Add the immediate parent's goal path to the representation of call
> 	events; this allows us to place the call in the body of its parent.
> 
> 	Expand the representation of atom arguments to include their HLDS
> 	variable numbers, and a boolean that says whether the argument
> 	is a programmer-visible headvar.
> 
> 	Use this extra information to add support for indexing lists of
> 	arguments from either the user view or the implementor view.
> 
> 	Add field names to several types.
> 
> browsers/program_representation.m:
> 	Add a field to plain calls, giving the name of the module defining
> 	the called procedure. This is necessary to reliable distinguish

s/reliable/reliably/

> 	the builtin unify and compare procedures, calls to which must be
> 	handled specially because they generate no events. (They don't need to,
> 	since they are correct by construction.)
> 
> 	Add mechanisms for converting goal paths from strings to structured
> 	terms, for use by the dependency tracking code.
> 
> 	Add tests on atomic goals, for use by the dependency tracking code.
> 
> 	Add a mechanism to let C code retrieve the types of proc_reps as well
> 	as goal_reps.
> 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------