[m-dev.] logging proposal

[Julien Fischer]

On Sun, 19 Mar 2006, Mark Brown 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?
>
> 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 agree.

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

That was just a really bad example on my part.

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