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

[Ralph Becket]

>From Mark Anthony BROWN on 12/10/2000 10:55:04
> 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.

That would be smashing!  I'm in the middle of a two, or possibly three,
pipe problem and improved term printing would be a real help.

One major pain I have at the mo. with mdb is that when I do
`save .mdb' it doesn't save the browser settings, so I have to
go through `set format pretty; set depth 100; ...' every time
I restart mdb.

As an aside, the term browser seems geared towards exploring single,
very large terms, such as are found in, say, the internals of a
compiler. However, there is also a large class of problems where the 
terms involved are relatively small and one wants to compare two or 
more at the same time (e.g. before and after states).  This is where
mdb's `print' command would be most helpful, but currently isn't.

> 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 have a version of pprint__to_doc that formats lists as [1, 2, 3]
and 234-trees as tree234([k1 -> v1, k2 -> v2, ...]), although it
doesn't work properly yet as I haven't put in Fergus' fix to recognise
univs matching polymorphic types.  I can supply this soon, though.

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

Rather than have the user supply code, have them tell mdb (e.g. in
.mdbrc) what pprint formats to use for various types.

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

Sure, but if you can get `print' to be more helpful I'll buy you a beer.

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

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