[m-dev.] collect

[Fergus Henderson]

On 11-Jun-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> 
> For a few months now , I am working on monitoring of Mercury programs
> (as well as test coverage).  [...]  I've shown how a variety of such
> dynamic analysis can implemented with Opium-M.  [...]  Each of them only
> required a few dozens of lines of Opium-M code. Hence any user would be
> able to write such monitors (or any variation of existing monitors that
> exactly fits to their needs).
>
> The main advantages of this approach are :
> - the simplicity of use (any user can get the monitor he needs),
> - the flexibility,
> - the synergy between tools.
> 
> The main drawback is of course efficiency due in particular to socket traffic
> and context switches between the debugger and the debuggee.

Another drawback is the need for the user to learn two languages:
as well as knowing Mercury, they also need to learn the Prolog-based
Opium-M command language.

> That is the reason why I am currently designing and implementing a primitive
> (that we called `collect', but I'm not absolutely happy with that name...) that
> would allow to optimize that approach. This primitive avoid all the
> communications between Opium-M and debbugee by analyzing the whole program
> execution in one pass. Of course, I want this primitive to allow the same
> flexibility and the same ease of use as with the Opium-M approach.
> 
> The `collect' is described in more details in a article that I submitted 
> recently and that is available at:
> http://www.irisa.fr/EXTERNE/projet/lande/jahier/collect.ps

This looks like it could be a very elegant approach!

I'd like to see something along these lines become part of the standard
Mercury distribution.

The paper skimmed over a few things -- I'd like to know more of the details.
For example, the interface to `collect' is not entirely clear -- what are
the types of the arguments?

It might be more elegant if the dynamically linked module defined a single
function returning an instance of a standard typeclass, rather than defining
a type and two specific predicates acting on that type, with specific
argument types, modes and determinism.  This would of course require
existential types ;)  The interface would then always look like this

	:- module foo.
	:- interface.
	:- import_module collect.

	:- some [T] func make_collector = T => collector(T).

and the implementation would look something like this

	:- implementation.

	% this one just counts the number of events

	:- type state ---> state(int). % or whatever

	make_collector = state(0).

	:- instance collector(state) where [pred(filter/3) is do_filter].

	do_filter(_Event, state(N), state(N+1)).

Also, it might be a good idea to make `filter' also return a bool
which says whether to keep on going -- some filters need not examine
the whole trace.

This kind of approach could also be extended to provide features like
conditional breakpoints in the internal debugger.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------