[m-rev.] For revew: a new, improved pretty printer

[Zoltan Somogyi]

On 01-Aug-2007, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > it more readable and to avoid the ambiguity with the constructor used in
> > string.format.
> 
> What do you suggest?  Is this overloading of s/1 likely to cause
> trouble?

str/1? literal/1?

> How about this:
> 
> % pp_list([X1, X2, ..., Xn], Sep) expands into
> %
> %   docs([set_arg_priority, open_group, nl, pp_univ(X1), Sep, close_group,
> %         set_arg_priority, open_group, nl, pp_univ(X2), Sep, close_group,
> %         ...,
> %         set_arg_priority, open_group, nl, pp_univ(Xn), close_group])
> %
> % although later list items will appear as just "..." if the term depth
> % limit is reached.

That looks OK, but I would also retain the existing comment (without the false
N to N implication) as the main explanation, with this being the clarification.

Note: I don't think squeezing that comment into the last 20 or so columns
would work.

> > Are there limits on what docs are permissible or sensible separators?
> 
> No.

You may wish to document this fact.

> > > +    ;       set_op_priority(ops.priority)
> > > +                                        % Set the current priority for printing
> > > +                                        %  operator terms with the correct
> > > +                                        %  parenthesisation.
> > 
> > What is the scope of this effect? Why isn't the scope a doc supplied as an
> > argument?
> 
> The scope extends to the next set_op_priority doc.

> > > +    ;       set_limit(pp_limit).        % Set the truncation limit.  This
> > > +                                        %  should not be necessary for user
> > > +                                        %  defined pretty printers!

It seems to me that sensible uses of set_op_priority and set_limit use them
in a stacklike fashion: override them for some subterms, but then restore
the original value after them. To that end, have you considered replacing
set_op_priority with push_priority and set_limit with push_limit, with
the implementation maintaining a stack, and new pop_op_priority and pop_limit
alternatives to pop them? I think that would make docs easier to create
by not requiring the users themselves to keep track of the stack. It would
also make easier to detect screwups by users who DO use either mechanism;
if the op stack and limit stack aren't in their original states at the end
of processing the doc, there was a mismatch.

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