[m-dev.] logging proposal

[Ian MacLarty]

On 3/19/06, Mark Brown <mark at cs.mu.oz.au> wrote:
> 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.
>

You are never going to be able to completely separate the meta goals
from the other goals, since, for example, a meta goal could write to a
file that is later read by the code at the object level, thus
affecting the semantics of the object code.

That said, perhaps we could deal with the problem of meta code
throwing exceptions by catching any exceptions thrown by the meta
code, wrapping them in a special functor and rethrowing them.  We
could then alter the try predicate to always rethrow exceptions
wrapped in the special functor.  Thus if meta code throws an exception
then the program aborts (so I guess it still affects the semantics of
the object code, only in a very obvious way).

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

I'm not really following this part of the discussion.  What's the
issue here?  If the trace goals are enabled then they cannot be
optimized away or reordered in the predicate they appear in.  If the
predicate the trace goal appears in is optimized away by the compiler,
then it is equivalent to true in the semantics of the object code and
why would anyone write a pure predicate always equivalent to true?

I want to avoid people defining new predicates that just call trace goals like:

:- pred trace_print(string::in) is det.

trace_print(S) :-
    trace [!IO] ( io.write_string(S, !IO ).

This should be avoided because there's no indication at a call site of
trace_print that it has meaning only at the meta level.  In my opinion
the compiler should have every right to optimize away calls to
trace_print.  The user should put explicit trace goals where they want
to observe execution, not call meaningless predicates that then call
trace goals.

Ian.

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