[m-dev.] logging proposal

[Mark Brown]

On 19-Mar-2006, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> 
> On Sun, 19 Mar 2006, Ian MacLarty wrote:
> 
> > On Mon, Mar 13, 2006 at 11:26:31AM +1100, Julien Fischer wrote:
> > >
> > > On Sun, 12 Mar 2006, Ian MacLarty wrote:
> > >
> > > > Index: doc/reference_manual.texi
> > > > ===================================================================
> > > > RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
> > > > retrieving revision 1.345
> > > > diff -u -r1.345 reference_manual.texi
> > > > --- doc/reference_manual.texi	8 Mar 2006 02:25:38 -0000	1.345
> > > > +++ doc/reference_manual.texi	11 Mar 2006 14:29:07 -0000
> > > > @@ -642,55 +642,6 @@
> > > >
> > > > +
> > > > + at item @code{debug @var{Vars} @var{Goal}}
> > > > +A goal used only for the purposes of debugging.
> > > > + at var{Vars} is a list containing exactly two variables of the
> > > > +type io.state.
> > > > + at var{Goal} is a deterministic goal that may perform I/O using the
> > >
> > > Presumably it may also be a cc_multi goal?
> > >
> >
> > I guess so, but I don't think the cc_multiness should affect the
> > determinism of the predicate the debug goal is in.  Agreed?

Yes, agreed.  You should think of these goals as being "meta-goals" -- at
the object level (that is, the ordinary level of the program) they have no
meaning.  So any I/O that they do is only considered to affect the state
of the meta-world, and any nondeterministic choices they make are only
choices at the meta level, not the object level.

This is precisely how we think of the existing debugger code in browser/,
which does I/O and is committed choice, but which is never intended to
affect the object level semantics.

One issue that this raises relates to exceptions being thrown in meta-goals.
They shouldn't be caught at the object level, I guess, but I'm not sure
about the best way to deal with this.

> 
> Yes; we could just consider cc_mutli goals inside debug goals to implictly be
> in a promise_equivalent_solutions scope (I expect the situation wouldn't
> really arise that much in practice.)

It would arise in practice for the same reason that the browser code is
cc_multi, namely that you would use deconstruct_cc (or equivalent) to make
sense of higher-order terms.  I think it's best to avoid thinking of there
being a promise in this situation.  Thinking of it that way just conflates
the object and meta levels, and in any case such a promise would generally
be a lie so we should avoid explaining debug goals that way in the
reference manual.

> 
> > > > +io.state variables in @var{Vars}.
> > > > +When debug goals are disabled they are equivalent to the goal @samp{true}.
> > > > +When debug goals are enabled they are equivalent to the impure goal
> > > > + at code{impure make_io_state(IO0), Goal, impure consume_io_state(IO)}
> > > > +where IO0 and IO are the names of the variables given in @var{Vars} and
> > > > + at code{make_io_state/1} constructs a fake @code{io.state} variable and
> > > > + at code{comsume_io_state/1} destroys the fake io.state, with the exception that
> > > > +the impurity need not be propogated to the predicate the debug goal
> > > > +appears in.
> > >
> > > So for the purposes of code in these debug goals impurity is effectively
> > > ignored?
> > >
> >
> > Only in the sense that the impurity doesn't propogate to the parent.
> 
> But then how much latitude is the compiler going to have to optimize code
> containing debug goals?

Good question.  The strictness of mdb's events is determined by the
`--trace-optimized' option.  Perhaps we shohuld go by this or something
similar.

I think that, as with the current debug events, users would expect their
debugging goals to be strict.  If they want to observe the optimized version
of their program they can ask for it with a compiler option.

> At the moment because debug goals are effectively
> considered pure in their parents this would seem to be quite a bit.  I don't
> think this is going to be all that effective if the compiler decide that it
> can optimize away all the debug goals.  (And yet there would be some
> circumstances where they should (arguably) be optimized way, if they occur in
> unreachable code for example.)

Agreed, although I don't see how optimizing unreachable code will make any
difference whatsoever.

Cheers,
Mark.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------