[Haskell-cafe] haskell-src-exts Question

[Duncan Coutts]

On Fri, 2009-11-13 at 20:08 +0000, Neil Mitchell wrote:
> Hi Niklas,
> 
> >> Do I have to write my own prettyprinter? Do I have to put in explicit
> >> parentheses? The latter seems unsatisfactory as my generated AST is unambiguous
> >> and bracketing ought to be part of the prettyprinter. The former would be quite
> >> a lot of code as there are many cases to consider.
> >
> > Looking at your example, what you want is brackets to be inserted
> > whenever the right subexpression in an application is non-atomic. That
> > certainly seems reasonable to me. Would you file a ticket for it
> > please? http://trac.haskell.org/haskell-src-exts :-)
> 
> I wanted that once, then I realised I was wrong :-)

Surely you do want this. It's the biggest problem with the original
haskell-src package, that it cannot print out any useful Haskell code
obtained from the parser, because it forgets all the brackets.

> Should you insert brackets everywhere it's ambiguous?

The minimal number that are necessary. The Show class manages to do this
ok.

> What about operators - you don't know the fixities, so can't tell if
> you should insert a bracket or not.

You can at least remember enough in the parser to print it out the same
way. If we do not have fixity info available (eg because it's from some
other module) we just keep the operators and expressions together in a
list (such that they could be fully resolved if we applied fixity info)

eg

e1 %% e2 ?? e3

as (using made up AST names)

(e1, [(Op "%%", e2), (Op "??", e3)])

We can then print it out the same way. We could also resolve the
bracketing if we had fixity info and in that case we could print out the
expression again with the minimal number of brackets necessary.

I did it like this for an undergrad compiler, the round trip parsing and
pretty printing works fine, as does getting from the plain syntax level
to the fully resolved level by using fixity info.

> I can't see any way for HSE to implement this feature correctly, and
> as such, it's really not a good feature to push down in to the pretty
> printer.

It probably wants to be a combination of the parser, AST and pretty
printer.

Duncan