[m-dev.] Re: Calling an arbitrary predicate from mdb

[Peter Schachte]

On Tue, Dec 01, 1998 at 11:27:28PM +1100, Tyson Dowd wrote:
> On 01-Dec-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 30-Nov-1998, Bert Thompson <aet at cs.mu.OZ.AU> wrote:
> > > The simpler solution therefore, is to link with a library of
> > > preds for displaying data structures from the library. Any user-defined
> > > display preds could also be loaded in, possibly dynamically.

I would think a "browseable" type class would be about right here.
The only trouble with that is that it's important that every
discriminated union type be browsable with a standard default browser,
but still allow the user to override the default browsing code if she
wishes.  In this sense, browsing is just like printing, so whatever
technology is to be used to handle printing would probably be the
appropriate choice for browsing as well.

> The difficult part is that you need to keep a list of all the display
> preds available, despite the fact that they are defined in different
> modules.
> 
> One way to do this is to have some sort of pragma declaration that
> adds some initialization code to the initialization section of the
> module that registers each display predicate -- putting them into
> some sort of global table.

First let me say that I think the idea of an initialization pragma is
a good one.  It's not needed very often, but when it is needed,
working around the need is pretty painful.

However, this doesn't seem like a good way to handle this particular
problem.  Something more static would seem to be a better choice, like
using a type class.  If the type class system provided a predicate for
checking if a term (or a type) is in a type class, then one could
write something like

	:- pred print(T::in, io__state::di, io__state::uo) is det
		<= writable(T).

	print(T) -->
		{ in_type_class(T, printable) } ->
			print_printable(T)
		;   write(T)
		).

Something like would seem sensible for browsing, too.

I also think it's important, though, for users to be able to indicate
that certain predicates are only used when debugging, and should not
be included in final executables.  This may be as simple as a switch
to turn on and off dead code elimination, but in this case dead code
elimination needs to be pretty clever about type classes.

> > > Ideally, you should be able to load and unload a Mercury-compiled
> > > shared object from the debugger commandline also.
> 
> Yes, well, as discussed at the Mercury meeting today this is a big
> step for a rather small functionality gain.

I can't comment on how big a step it is, but I think the gain in
functionality is potentially very significant.  If, for example, the
compiler could load code at runtime, it would be possible to implement
preprocessors of various sorts (eg, the global variable package I
described yesterday) as external bolt-ons, rather than having to build
every such thing into the compiler itself.  Being able to plug in
other specialized program analyzers, too, would be very useful.  It
would be useful for other applications, too, to be able to dynamically
load and call code, for example the battleship program mentioned in a
recent mail message, if I understand what it's meant to do, would
benefit by being able to load two separately-written player modules.

-- 
Peter Schachte                | The end of the human race will be that it
mailto:pets at cs.mu.OZ.AU       | will eventually die of civilization.
http://www.cs.mu.oz.au/~pets/ |     -- Ralph Waldo Emerson 
PGP: finger pets at 128.250.37.3 |