[m-dev.] diff: use pretty printer in mdb

Ralph Becket rbeck at microsoft.com
Tue May 23 18:47:05 AEST 2000


> From: Mark Anthony BROWN [mailto:dougl at cs.mu.OZ.AU]
> Sent: 22 May 2000 20:11
> To: mercury-developers at cs.mu.OZ.AU
> Subject: Re: [m-dev.] diff: use pretty printer in mdb
> 
> > In what sense are you using `size' here?
> 
> The number of functors in the term.  If there is a large branching
> factor in the displayed term, and the depth limit is not low enough,
> then a ridiculously large term might still be displayed.

Right, that should be easy enough to put in.  It seems to me that
seeing just the first few args of a functor is probably not that
useful and that one might just as well replace the whole arg list
with ellipsis.

Another thing that ocurred to me was that it might be better to
replace `foo(...)' in the output with `foo/3' or whatever.

Any strong opinions on the matter?

> >  The existing code (which
> > will go horribly wrong on very large terms [performance bug - a 
> > fix is in the pipeline]) allows you to specify the depth to which
> > pretty printing will go - as you've made provision for - and it
> > allows you to specify the notional display width (which it will
> > overrun if that cannot be avoided).
>
> As for the performance problem, I think it can be solved by threading
> the available width through flatten, which should fail if there is not
> enough room for the flattened document.  This will allow the 
> condition (in be/3) to fail before the recursive call.

The performance bug is now fixed - see following "for review" msg.
The pretty printer now laughs in the face of large terms and tweaks
the nose of bushy trees.

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



More information about the developers mailing list