pretty newby

[John Hughes]

On Wed, 24 Sep 2003, Luc Taesch wrote:

> alos, Im surprised that this bland issue has not already been solved (PP
> lib paper looks dated 96). no offence intended, but aas im newbie, i
> wonder what am i missing ? what is different in the process of creation
> so that this need did not arised already? i should admint i'm puzzled,
> given the facilities at hand...

As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or
at least explain what it offers, and what it does not.

The problem I was solving in that was paper was how to pretty-print
*data-structures* from inside a program. That includes abstract syntax
trees in compilers -- in fact, that's maybe the most important
application. The library is used in GHC, for example, to pretty-print
programs at various stages, after varying degrees of transformation. You
the user can see what the compiler has produced after each phase, and you
see it laid out in a readable format.

Pretty-printing data-structures is quite different from pretty-printing
*programs* -- we should have two different words for it, really! When you
pretty-print a program, you just want to change the layout in an existing
text, and comments etc. ought to be preserved and appear in sensible
places afterwards. When we pretty-print programs, there is an input (the
program as you wrote it) to take into account. When you pretty-print a
data-structure, you're just trying to output something produced by a
program... there is no "input" it was produced from which the
pretty-printed output ought to resemble.

So, if you want to see what GHC has produced after phase X, then the
pretty-printing library is appropriate. Of course, if there were comments
in the program you wrote, then you ought to realise the compiler discarded
them early, and you should not expect them to appear in the result of
various transformations/optimisations.

But if you want to standardise the layout of a program you wrote, then
this is no good. The pretty-printing library is not sufficient to do this
by itself... it solves a different problem. It is possible to BUILD a
program pretty-printer using the library (although this is not the only
possible approach), but it requires combining the library with a parser
which loses no information, in particular including comments at the
appropriate places in abstract syntax trees, so that they are a part of
the data structure being pretty-printed.

The problem is that parsers in compilers don't keep track of comments...
instead they discard them at the first opportunity (during lexing). Thus
such a parser, combined with a pretty-printer, cannot solve the *program
pretty-printing* problem.  What's needed is a parser that can parse
comments, and tie them to the *right place* in the abstract syntax tree.
Figuring out what a comment is really commenting is probably extremely
hard... But without an AST with attached comments in the right places, my
pretty-printing library, and Simon PJ's extension, are useless.

That said, maybe it is surprising that no good Haskell pretty-printer has
appeared yet, especially given the importance of layout in the language.
Why not write one? I dare say there would be many users, and no doubt you
could publish a paper at the Haskell Workshop...

John Hughes