[m-dev.] logging proposal

[Ian MacLarty]

On 3/18/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
> > > > +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.

They are not considered pure in the sense that they cannot be
reordered or optimized away (when they are enabled).

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

They wont be optimized away, unless the compiler decides to optimize
away a call to a predicate containing the debug goal.

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

What about 'trace' goals?

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

I think I agree, though Mark's concerns are still valid.  Are there
any other opinions on this?

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