[m-dev.] User-controlled pretty-printing

[Ralph Becket]

Peter Schachte, Thursday, 14 December 2006:
> On Thu, Dec 14, 2006 at 09:44:15AM +1100, Ralph Becket wrote:
> > So, what we want is:
> > 
> > - the ability to navigate to a subterm using an abstract address
> >   e.g., go to the "3rd list item" rather than navigating through cons
> >   cells with "2/2/2/1";
> 
> How about navigating by unfolding recursive types and counting only
> non-recursive arguments?  This means you select the 3rd list element
> by saying just "3."

We do want to be able to distinguish abstract and concrete addresses.
We'll need some distinguishing address syntax or have a modal navigation
interface.

> For a binary tree type, "3" would specify the
> third non-recursive argument in a left-to-right depth-first traversal.
> By "non-recursive argument" I mean an argument of the term with
> different type than the term itself.  So for a type
> 
> 	tree(T) ---> empty ; tree(tree(T), T, tree(T)).
> 
> we'd only count the second argument of the tree/3 term.  In this case,
> 3 would specify the third element in a depth-first left-to-right
> traversal of the tree.  It would be similar for a 2-3-4 tree, except
> that the internal nodes come in three different flavours, and
> different flavours have different numbers of non-recursive arguments
> to count.

Wouldn't this have problems with non-canonical types?  That is, the
pretty printer might show you a term in a canonical representation, but
the actual underlying representation might be one of several different
forms.  In situations like this we'd find abstract address "3", say,
takes us to different places in terms that happen to pretty print the
same.

> The big shortcoming of this is in handling types with a real
> pretty-printer defined.  Eg, you'd really rather display at a 2-3-4
> tree something like
> 
> 	"apple" -> big_term(...)
> 	"banana" -> big_term(...)
> 	"orange" -> big_term(...)
> 
> In this case, you'd probably be OK.  You'd specify "4" to examine the
> mapping for "banana," which seems intuitive enough.

I would not find that intuitive; to me the natural interpretation of the
abstract address "4" is "the 4th key-value pair in this map when
represented as an assoc_list".

> But other
> pretty-printers may exhibit little relation between the order subterms
> are shown and the order they appear in a left-to-right traversal of
> the term.

Indeed.

> Let's face it:  what you really want is to be able to click on a
> subterm with the mouse.

I'm pretty sure we can make this work without the need for a
point-and-click interface (although that might not be a bad idea if we
could get hold of a keen summer student...)

-- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------