[m-dev.] Contribution: Pretty Printing Library

[Mark Anthony BROWN]

Mark Anthony BROWN writes:
> 
> Hi,
> 
> Here's my first round of review comments.  I still have a few
> things to look into...There'll be more to come.
> 

Here's the next lot.  There are still some outstanding issues:

	- Copyright stuff.  I'd rather leave discussion of this to
	  someone who knows what they are talking about.

	- As Fergus suggested, nesting could be handled more
	  abstractly.  I'll comment on this later, if I can think
	  of anything worthwhile.

	- Where the module should go once it passes review.  A likely
	  destination is the extras directory, which contains various
	  other "non-standard" libraries.  I don't know how well this
	  would fit with doing field trials like using it in
	  error_util.m (as Fergus suggested) or in the term browser
	  (as I would like to do).  Comments, anyone?

Aside from these issues, and the ones below, I am happy for the module
to pass review.

Cheers,
Mark.

Ralph Becket writes:
> %
> % 4. group(
> %   text("Goodbye ") `<>`
> %   nest(2, line `<>` text("cruel ") `<>` line `<>` text("world")
> % )
> %
> %   Goodbye cruel world
> %
> %   Goodbye
> %     cruel
> %     world

There is a slight chance that a reader may interpret this example
as having something to with right justification of the text (atleast,
until they think about it for a moment).  This possibility could be
removed, e.g., by changing the amount of indentation.

> %
> % 5. group(
> %   text("Goodbye ") `<>`
> %   nest(2, line `<>` group(text("cruel ") `<>` line `<>` text("world")))
> % )
> %
> %   Goodbye cruel world
> %
> %   Goodbye
> %     cruel world
> %
> %   Goodbye
> %     cruel
> %     world

Ditto.

> 
>     % separated(PP, Sep, [X1,...,Xn]) = PP(X1) `<>` Sep `<>` ... Sep `<>` PP(Xn)
>     %
> :- func separated(func(T) = doc, doc, list(T)) = doc.

I'm not convinced that this is the best interface.  What are the
arguments for/against the higher-order abstraction?

    - It doesn't buy a lot in terms of expressiveness, since you can
      achieve the same effect by combining a call to `separated'
      with a call to `list__map'.
    - However, that would require an extra traversal of the list,
      so it would be less efficient.
    - But in the common case that the first argument is the identity
      function, the abstraction is unnecessary.

Comments, anyone?

At the least, it would be good to have a version of `separated' which
was specialised for the first argument being the identity:

:- func separated(doc, list(doc)) = doc.

>     % Convert arbitrary types to docs.  This requires std_util__functor/3
>     % to work on all components of the object being converted.  The second
>     % version places a maximum depth on terms which are otherwise truncated
>     % to `...'.
>     %
>     % XXX This throws an exception if the term in question has user-defined
>     % equality.
>     %
> :- func to_doc(T)           = doc.
> :- func to_doc(int, T)      = doc.

What is the depth of the root node?  0 or 1?  How is the behaviour
defined for negative depth limits?

(I know the answers to these questions from looking at the
implementation, but they should be documented here.)

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