[m-dev.] Contribution: Pretty Printing Library

[Ralph Becket]

> > % 'GROUP' constructor and altered flatten/1 and be/3 
> appropriately.  because
> 
> s/because/Because/

Done.

> > % 'UNION' only arises as a consequence of processing a 
> 'GROUP' it turns out to
> > % be simpler to do away with 'UNION' altogether and convert 
> clauses that
> > % process 'UNION' terms to processing 'GROUP's.
> > %
> 
> The change is OK so far as correctness is concerned, but
> is there any chance that 'UNION's may be wanted for a non-'GROUP'
> purpose in future?  If so, this decision may need to be reversed.
> However, it's probably alright to leave it as it is for now, since
> doc is an abstract type.

Not unless we deviate substantially from Wadler's algebra.  A `UNION'
encapsulates all the possible ways of laying out a doc.  This sort of
thing works fine in a lazy language like Haskell, but it's a 
performance cow in a strict language.  Since a group is the only way
a lay-out decision can be introduced, it was easier to just embed the
decision code with that for handling `GROUP's.

> > % The second change is that flattened `line' breaks become 
> empty strings
> > % rather than spaces.
> > %
> 
> This is a good decision, IMHO.  But it might be worth giving some
> more detail here about the ramifications, eg, needing to put a
> space at the end of a line even if it is not required by the 
> unflattened
> version.

I don't understand - you only have to put spaces in if they're
absolutely necessary.  One possibility, suggested by Wadler, is
that we could introduce special `line' variants that include
alternate text if they get flattened - so we might have

	text("blah blah") `<>` or_line(" ") `<>` text("rhubarb")

where we either get a line break or a single space in the middle.
Do we really need this, though?

> > % There are two stages in pretty printing an object of some type T:
> > % 1. convert the object to a pprint__doc using some 
> specially written
> > %    function;
> 
> Or you could use one of the generic to_doc functions.  ;-)

I wrote pprint__to_doc/[2,3] specially for this purpose :)

> > % Below are some docs followed by the ways they might be 
> displayed by the
> > % pretty printer.
> 
> I'd append ", with various line widths" to that sentence, or words
> to that effect.

Done.

> > 
> >     % A word of explanation about group/1.  `group(Doc)' 
> gives the pretty
> >     % printer the option of fitting Doc onto one line if 
> possible by removing
> >     % all the new-lines and nest-spacing from it; if this 
> doesn't work then
> >     % the pretty printer will just interpret Doc literally 
> (of course, Doc
> >     % may contain other `group'ed items.)
> 
> This comment is probably redundant, now that the primitives are
> described in the header.  Here you may wish to refer readers to that
> documentation, though.

Okay, I've elided it.

>      % This causes a runtime abort if the term in question 
> has user-defined
>      % equality.
> 
> I think this doesn't need an XXX, since it is reasonable to make this
> actually part of the specification, not just an unimplemented feature.

I've adopted Fergus' suggestion:

% This may throw an exception or cause a runtime abort
% if the term in question has user-defined equality.

> s/page width/line width/

Done, and added that the width is specified in characters.  I've also
amended the description of text/1 in the header to

% text(string)
%   the document consisting of a single string - note that the
%   pretty printer assumes that every character in a text string is
%   printable and occupies a single character cell on the printed
%   screen, so tabs and newlines etc. should be avoided;

Cheers,

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