Operating on HsSyn
sh.najd at gmail.com
Fri Jul 28 20:11:02 UTC 2017
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
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 .
Having said all these, we ARE diverging from the original thread, and
How about taking printer-design related discussion to the following wiki
page (and/or a new ghc-dev thread if needed):
On Fri, Jul 28, 2017 at 8:43 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
> 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)
> On 28 July 2017 at 20:34, MarLinn <monkleyon at gmail.com> wrote:
>> (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:
>> parser . prettyPrint ≍ id
>> prettyPrint . parser ≍ id -- ∷ String → String, useless here
>> prettyPrint . parser . prettyPrint ≍ prettyPrint
>> 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.
>> ghc-devs mailing list
>> ghc-devs at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs