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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell