[m-dev.] Contribution: Pretty Printing Library

[Mark Anthony BROWN]

Ralph Becket writes:
> 
> > 
> > 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.
> 

Ok.

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

For example, comma_space_line/0 is useful for writing lists,
but it might appear strange to be putting a space just before a line
break where it generally can't be seen.  Of course, the space is
visible if the list is flattened out, so it is not at all strange
to put it there.  You don't have to worry about this with Wadler's
version.

I just thought that here might be a good place to document this effect.
Come to think of it, it would be good place to document the rationale
behind using this variation in the first place.

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

No, I don't think so.  I'm happy with comma_space_line.

> 
> > > % 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 :)

Ah, I thought you meant specially written _by_the_user_; ie. functions
they write especially for their own types.  It might be worth
mentioning that there are two approaches to this step: define
your own function, or use the generic library version.

> 
> I've adopted Fergus' suggestion:
> 
> % This may throw an exception or cause a runtime abort
> % if the term in question has user-defined equality.
> 

Ok.

> > 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,
Mark.
-- 
Mark Brown, PhD student            )O+  |  "Another of Fortran's breakthroughs
(m.brown at cs.mu.oz.au)                   |  was the GOTO statement, which was...
Dept. of Computer Science and Software  |  uniquely simple and understandable"
Engineering, University of Melbourne    |              -- IEEE, 1994
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------