[m-dev.] pprint performance

[Fergus Henderson]

On 25-Feb-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> Kevin Glynn, Monday, 25 February 2002:
> > 
> > I know nearly nothing about the problem you are solving,  but looking
> > at what you write below, isn't this really where laziness pays off?
...
> The problem is that when you pretty-print a term T you generally
> do something like
> 
> 	pretty_print(mark_up(T))
> 
> where mark_up converts an arbitrary term into a marked-up structure
> showing where the various choice points are for the pretty_print
> function.
> 
> Each part of T may well be marked up lazily, but as each part is
> converted, the result becomes reachable (because it overwrites the
> thunk) from the result of the call to mark_up.  Since pretty_print
> has to traverse the whole marked up term, the garbage collector can't
> actually collect anything of mark_up(T) until the pretty printer has
> finished (it's all reachable data up to that point).

If the garbage collector is properly liveness-accurate,
and you code the algorithm carefully,
then the parts of the tree which have been printed out
should not remain live and so should be garbage collected.
After each sub-term has been fully traversed by pretty_print,
it should be possible for the GC to collect it.

> Kevin Glynn:
> > I think this is where explicit laziness doesn't work, you can't just
> > make the outer call lazy, you havve to make all the internal parts
> > lazy too. Too painful.

I'm still not yet convinced that it is too painful.

Note that after Ralph's change to higher-order function insts,
you don't need to use special modes to make use of explicit
lazy evaluation any more.  You just need to use the lazy(T) type,
and to insert explicit calls to `force' whenever the type checker
tells you they are needed.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------