[m-dev.] for review: add mdb support for interactive queries

[Fergus Henderson]

On 15-Mar-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Sat, Mar 13, 1999 at 09:37:45PM +1100, Fergus Henderson wrote:
> > On 11-Mar-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> > > When you're debugging a particular module, however, you are probably
> > > not interested in any modules other than the one you're debugging, the
> > > ones it imports, the ones they import, and so on. For such cases, it
> > > would be useful to focus on a particular module, and thereby limit
> > > visibility to modules recursively imported by the focus module.
> > > 
> > > How does that model sound?
> > 
> > Imports in Mercury are never transitive (well, modulo compiler bugs).
> > So I prefer to just include the directly-imported modules.
...
> The argument for using transitive imports in the debugger is just for
> convenience.  When debugging, one often finds one must piece together
> a goal from many modules and different levels of the system.  In such
> situations one really wants a looser visibility system than one would
> want when programming.

That seems reasonable.

> This transitive import is really just a generalization of the model
> that all modules linked into the system are visible.  If you pick the
> root module of the system as the current focus, then "all modules
> transitively imported by the focus module" is the same as all modules
> linked in.
> 
> This model seems much more consistent to me than the model that in the
> default situation, all modules are visible, but when you set a focus
> module, only those directly imported are visible.

How about just keeping all modules visible, then?

That is, the default is that the interfaces of all modules in the program
are visible; when you set a focus module, the interfaces of all modules
are still visible, the only change is that you now also get access to
the private parts of the focus module.

> >   module	[<main-module> [<imported-modules list>]]
> >   import_module	<imported-modules list>
> >   use_module 	<used-modules list>
> > 
> >     The `module' command sets the focus module and resets the imported-modules
> >     list.  The `import_module' and `use_module' commands add modules to the
> >     lists of imported and used modules.
> 
> This seems a bit inconsistent naming-wise.  It's also a bit clumsy
> when you want to remove a pesky import that keeps causing clashes:
> you have to reset the imports and add back all the other modules.
> Maybe allow individual module names preceded by + or - to specify
> adding or removing modules from the current list?
> 
> >   query    	[<main-module> [<imported-modules list>]]
> >   cc_query 	[<main-module> [<imported-modules list>]]
> >   io_query 	[<main-module> [<imported-modules list>]]
> 
> Where are the actual queries specified?

After you type `query' at the `mdb>' prompt, you get a new prompt `?-'
where you can enter queries.  You can return from this prompt to the
`mdb>' prompt by typing end-of-file (normally control-D on Unix systems)
or `quit.'.

Likewise for the `cc_query' and `io_query' commands, except that
for the `io_query' command, then prompt is `run -->' rather than `?-'.

> > In debug grade, there ought to be a default main/2 which just invokes
> > the debugger.
> 
> Very nice.
> 
> > Then it would be nice to have
> > 
> >   load		<shared-lib>
> >   unload	<shared-lib>
> > 
> >     These would dynamically (re)load or unload a shared library.
> 
> I don't understand when you would want to use these.  Can you give a
> bit more description or an example?

Well, suppose that in addition we modify the `mdb' script so that if you don't
give it a command name, then it starts up a program which just contains an
empty module, thus using the default main/2 which just invokes the debugger.
Then you could do

	$ vi foo.m				# write my program
	$ mmake foo.depend
	$ mmake libfoo.so			# compile it
	$ mdb
	mdb> load libfoo.so			# load it into the debugger
	mdb> query				# and run it
	?- foo(blah, blah, blah).		
	fail.					# oops, the code has a bug!
	?- ^D
	mdb> ^Z
	$ vi foo.m				# fix the bug
	$ mmake libfoo.so			# recompile
	$ fg
	mdb> load libfoo.so			# load in the new code
	mdb> query
	?- foo(blah, blah, blah).		
	true.					# this time it works ;-)

I suppose it would also be useful to have a shell escape command in mdb,
so that you can could do

	mdb> shell vi foo.m
	mdb> shell mmake libfoo.so
or 
	mdb> !vi foo.m
	mdb> !mmake libfoo.so

rather than

	mdb> ^Z
	$ vi foo.m
	$ mmake libfoo.so
	$ fg

Also it might be nice if there was a single mdb command which would do
all three commands

	mdb> shell vi foo.m
	mdb> shell mmake libfoo.so
	mdb> load libfoo.so

and/or one to do just the last two of those.  (Of course the first
command should actually be "shell ${EDITOR-vi}" rather than hard-coding
"shell vi".)  For example, perhaps

	mdb> edit foo.m

could be defined to invoke the editor, invoke mmake to remake all the
currently loaded shared libraries, and then reload them, and perhaps

	mdb> ml libfoo.so

could be an abbreviation for

	mdb> shell mmake libfoo.so
	mdb> load libfoo.so

Then the scenario above would look like this:

	$ vi foo.m				# write my program
	$ mmake foo.depend
	$ mdb
	mdb> ml libfoo.so			# build it and load it
						# into the debugger
	mdb> query				# test it
	?- foo(blah, blah, blah).		
	fail.					# oops, the code has a bug!
	?- ^D
	mdb> edit foo.m				# edit, recompile, and reload
	mdb> query
	?- foo(blah, blah, blah).		
	true.					# this time it works ;-)

Then it's just a matter of wrapping a nice GUI around all this,
and changing the name & prompt from "mdb" (Mercury Debugger)
to "mde" (Mercury Development Environment) ;-)

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