[m-dev.] logging proposal

[Ian MacLarty]

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?

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

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

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