Operating on HsSyn

[Shayan Najd]

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 <alan.zimm at gmail.com>
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 <monkleyon at gmail.com> 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170728/d217f8b1/attachment-0001.html>