[m-dev.] logging proposal

[Julien Fischer]

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?

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

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

> +For example you may wish to observe the state of an executing
> +program by printing out the values of certain variables at different points
> +of execution.
> +In these cases it is unnessecarily restrictive to either thread
> +an I/O state through all of your program
> +(the program may be non-determinstic),
> +or to use the impurity system to achive the desired side effects
> +(since then the impurity must be propogated to all ancestors of the
> +predicate(s) containing the impure debugging goals,
> +even when the program is not being debugged).
> +
> +The Mercury language therefore supports a special type of goal called a
> + at emph{debug goal} (@pxref{Goals}).
> +Each debug goal has access to its own pair of io.state variables.
> +
> +For example:
> +
> + at example
> +	:- pred perform_computation(float::in, float::out) is det.
> +
> +	perform_computation(Input, Output) :-
> +		do_complex_calculation(Input, Ouput),
> +		debug [!IO] (
> +			io.format("input = %.8f, output = %.8f\n",
> +				[f(Input), f(Output)], !IO)
> +		).
> + at end example
> +
> +Mercury compiler implemetations are required to support a boolean switch
> +which allows the user to enable or disable debug goals at compile time.
> +Debug goals only produce side effects if the compiler option to enable them is

I suggest: s/Mercury compiler implementations/Mercury implementations/

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