Re: Operating on HsSyn

MarLinn, Thanks for correcting me, and spelling this out. I did mean what Alan mentioned: "re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans)". As I recall, we had to go a bit further to give 'Something' some more structure to take into account things like "(ignoring SrcSpans)" (e.g., to define exact-printers, etc). Provided I have failed twice to properly recall the invariant, I refrain from trying to recall the rest tonight :) Not diverging from my point above, as far as I understand, an ideal `Outputable` machinery is going to be a bit different from the traditional pretty printers. I believe with a proper design we can even reuse `Outputable` machinery and provide it as a pretty printer for Haskell terms. It resembles the scenario in Section 3.7 compared to Section 3.6 of Trees that Grow [1]. Having said all these, we ARE diverging from the original thread, and Simon's questions. How about taking printer-design related discussion to the following wiki page (and/or a new ghc-dev thread if needed): https://ghc.haskell.org/trac/ghc/wiki/HaskellSyntaxPrinters Cheers, Shayan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf On Fri, Jul 28, 2017 at 8:43 PM, Alan & Kim Zimmerman wrote:

I agree. 4 is the current GHC invariant.

i.e., re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans)

Alan

On 28 July 2017 at 20:34, MarLinn wrote:

...

by

(parser . prettyPrint . parser) = id

I meant

(prettyPrint . parser . prettyPrint) = id

for a valid input.

Simplifying, (parser ∷ String → something), and (prettyPrint ∷ something → String).

Therefore, (parser . prettyPrint . parser ∷ String → something) and (prettyPrint . parser . prettyPrint ∷ something → String).

Therefore, both criteria could only apply for (something ~ String). But as pretty printing adds quotation marks, not even that is true.

There are four formulations that might be applicable:

1.

parser . prettyPrint ≍ id 2.

prettyPrint . parser ≍ id -- ∷ String → String, useless here 3.

prettyPrint . parser . prettyPrint ≍ prettyPrint 4.

parser . prettyPrint . parser ≍ parser 5. Well, you could go beyond to (prettyPrint . parser . prettyPrint . parser ≍ prettyPrint . parser) etc…

I don't think 1 (or 2) follow from one of the last two. But 1 does imply them. So it is a stronger criterion than both, and therefore probably not the one to choose. Assuming the parser is internally consistent, 3 just says something about the internal consistency of the pretty printer, while 4 says something about the relationship of the pretty printer to the parser. Thus 4 looks like the best candidate for a criterion. Possibly with 3 as a secondary target.

Cheers, MarLinn

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs