[m-dev.] thoughts: script language for term browser

[Peter Schachte]

On Tue, Sep 01, 1998 at 07:15:15AM +1000, Fergus Henderson wrote:
> On 28-Aug-1998, Bert THOMPSON <aet at cs.mu.OZ.AU> wrote:
> > In order to display terms in as flexible a manner as possible,
> > we need a scripting language.
> 
> This is not the only possible way of providing that kind of
> functionality.  We could for example use the same technique as gdb:
> just allow calls to arbitrary Mercury predicates from within the
> debugger (e.g. `call my_print(X)').
> 
> I think in general if people are going to write fancy pretty-print
> routines to print Mercury data terms, it will be easier if they can
> do this in Mercury.  And if they do write such pretty-printers in
> Mercury, that will make it easier for them to reuse the pretty-printers
> in their Mercury programs.

I agree completely: you want to write your output routines in Mercury.
However, debugger output has different requirements than other output.
For one thing, in the debugger, one wants depth-limited pretty
printing.  It's also convenient to have a separate length limit to be
applied to lists and argument lists and other similar things.  For
example, you may want to see the first 10 mappings in a map data
structure, but only want to see terms 2 levels down.

Also, one may want different sorts of display for the same type at
different times.  I don't know if this would be a problem, but one may
want different output for different types that are all defined as
equivalences (eg, address == int: you may want to print addresses in
hex and ints in decimal).  Finally, one may want to turn different
parts (different arguments) of a term's display on and off.  This is
just a special case of wanting different output procedures for the
same type at different times, but it may warrant special treatment.

I do think that Bert is right that the output should be a box
language, rather than raw text.  This will make writing a pretty
printer for a particular type a lot easier, and will make it easier
(possible!) to produce a nice GUI debugger that displays a
pretty-printed term in a resizable window.  Here's an sketch of code
to pretty print a list:

	:- pred print_list(list(T):in, int:in, int:in, 
			display:di, display:uo) <= displayable(T) is det.
		% I'm sure I've got this wrong, but you get the idea.

	print_list([], _Depth, _Length) -->
		% Ignore length and depth bounds for empty lists
		display_string("[]").
	print_list([E|Es], Depth, Length) -->
		(   { Depth = 0 } ->
			display_depth_elision([E|Es])
			% Include term in elision so that interactive term
			% browser can expand elisions, and so that different
			% types of terms can be elided differently.
		;   begin_hv_box,	% display contents horizontally if
					% they fit, otherwise vertically
		    display_string("["),
		    display_indent("["), % indent following box the width 
					 % of the string if it is displayed
					 % vertically, otherwise do nothing
		    begin_hv_box,
		    print_list_elements([E|Es], Depth-1, Length, Length)
		    end_hv_box,
		    display_string("]"),
		    end_hv_box
		).

	print_list_elements([], _, _, _) --> [].
	print_list_elements([E|Es], Depth, Length, LenLimit) -->
		(   { Length = 0 } ->
			display_length_elision
		;   begin_h_box		% must display horizontally
		    display(E, Depth, LenLimit),
		    display_string(","),
		    display_space,
		    end_h_box
		).

DCGs may not be the right way to do this, because the bracketing
constructs are clumsier than box nesting would probably be.  Anyway, I
hope you get the idea that the output is not raw text but a nested box
language.

--
Peter Schachte                | History teaches us that men and nations
mailto:pets at cs.mu.OZ.AU       | behave wisely once they have exhausted all
http://www.cs.mu.oz.au/~pets/ | other alternatives.
PGP: finger pets at 128.250.37.3 |     -- Abba Eban