[m-dev.] logging proposal

[Julien Fischer]

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

> > > +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?  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.)

> > >
> > >  @node State variables
> > > @@ -8819,6 +8833,50 @@
> > >  		impure Ys = map(ImpureFunc, Ys).
> > >  @end example
> > >
> > > + at node Debug goals
> > > + at section Debug goals
> > > +
> > > +Sometimes it is useful for a program to have side effects only for the purposes
> > > +of debugging.
> >
> > It's also useful for other purposes, e.g. profiling.  Along that line I
> > would suggest that the following would also be useful:
> >
> > 	* a `debug' flag for the mutable declaration.  These mutables
> > 	  would only exist when the boolean flag was set to true (and
> > 	  can only be referred to from within debug goals).
> >
> > 	* some sort of `debug' flag for the initialise and finalise
> >           declarations.
> >
>
> I agree it would be useful for profiling but that raises two issues:
>
> 1.  Is `debug' a good name?  Should there also be a `profile' goal that
>     is just an synonym for debug?

What I was getting at here, is that `debug' may not be a general enough name
because you may want to generate logging traces for purposes other than
debugging.

> 2.  Should debug goals be allowed to be enabled in non debugging grades?
>     If not then you couldn't use debug goals to profile your app in hlc
>     grade for example.

I would argue that they should (particularly in light of the fact that
the debugger doesn't work in the hlc grades).

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