[m-dev.] What's the status of the print cmd in mdb?

[Mark Anthony BROWN]

Ralph Becket writes:
> >From Fergus Henderson on 12/10/2000 03:49:52
> > On 11-Oct-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> > > Towards the end of August there was discussion of extensions to
> > > mdb's top-level print command, which seemed to come to a universally
> > > agreeable conclusion.  Did anyone get round to implementing it all?
> > 
> > Which extensions did you have in mind?
> 
> Here's a pointer to the last part of the discussion I could find:
> http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mer
> cury-developers.0009/0007.html
> 

I've been working on this.  (It's the sort of problem that seems
innocuous at first, but before long you are up to your neck in details,
details, details.) It hasn't been high on my priority list, but I'll
get a move on if you're that keen.

> > > For that matter, why does `print' sometimes show lists in [1, 2, 3]
> > > form and sometimes in .(1, .(2, .(3, [])))?  Most odd.
> > 
> > If the term is small enough, it just uses `io__write', which uses
> > list notation.  But if the term exceeds a certain size, it can't
> > use `io__write', since `io__write' doesn't have any depth limit;
> > instead it uses the term browser's print routine, which does have
> > a depth limit but which doesn't use list notation.
> 
> Aha!  This parameter doesn't seem to be settable, which is a shame.
> 

That cutoff size was meant as a temporary workaround, I think.
A longer term solution would be to provide some generic mechanism
that allowed special notation for outputting certain types; not just
lists, but maps, sets, etc.  Hopefully it would be extensible so that
a user could add notation for their own types.  If we did this, there
would be no need to use io__write in the term browser.

I reckon the best way to do this would be to base it on pprint.m.  We
could design a new version of to_doc which, as well as a polymorphic
argument, takes some sort of table which maps types to functions.
The function for a type T, if it existed in the table, would convert
values of type T to ones of type doc.  If a type isn't mapped in the
table then the generic function based on deconstruct/4 could be used.
Users, if they wish to add a function to the table, could write the
function using the existing pprint operators.

I briefly discussed this with Zoltan earlier today, and he suggested
using an approach similar to how user-defined options are processed
in the standard library.

I haven't thought about it too much, though; it would be well worth
thinking about the design more before rushing in to the implementation
(well, that's my excuse anyway ;-)).

Any comments?

Cheers,
Mark.

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