[m-dev.] For review: declarative debugging back end (3/3)
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu Jul 16 18:08:51 AEST 1998
On 16-Jul-1998, Mark Anthony BROWN <dougl at cs.mu.OZ.AU> wrote:
>
> Even better, I could replace the last sentence of the comment by:
>
> In particular, this allows a module to represent data the same
> way inside atoms as out. This is quicker and more compact than
> using a uniform representation, because no conversion is required
> while building the EDT.
That would be fine.
> I could describe
> the overall scene in something like compiler/notes/compiler_design.html
> and make references to it from here. Or, when a front end is written
> I can point to it as an example of use.
> > > %
> > > % For missing answer analysis also, the goal justification is a
> > > % tree that corresponds to the structure of the program. It is
> > > % the dual of the above structure: it represents which atoms
> > > % were _not_ computed answers.
> > > %
> > >
> > > :- type miss_tree(A)
> > > ---> local_call(evaluation_tree(A))
> > > % ; some [E] external_call(evaluation_tree(E))
> > > % <= evaluation_atom(E)
> > > ; conj(list(miss_tree(A)))
> >
> > Shouldn't that be `conj(int)'?
>
> I don't think so. In Lee's declarative debugging scheme, the children
> of an `mp' node include `mp' nodes for each conjunct. A miss_tree
> holds the children of (the Mercury equivalent of) an `mp' node.
If a conjunction has a missing answer, it is not necessarily
the case that all conjuncts will have a missing answer;
only one conjunct need have a missing answer.
I thought miss_trees represented missing answers.
Is that not always the case?
(What does a `trivial' miss_tree mean?)
> Was my reference to it being a dual structure confusing?
Yes...
> I could
> change it to something like "Its purpose is the dual of the above
> structure's purpose..."
I suppose that would help.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
More information about the developers
mailing list