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 <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
