: Simon Peyton Jones
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman ; Jacques
Carette
Subject: Re: Operating on HsSyn
On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see
what the renamer has done?
Right. So if I understand correctly, with this semantics, `Output
Simon,
Back to your original questions:
1. I think we should probably use a superclass instead of a type synonym
>
> class (Data p, ForallX Data p, ) => DataId p where {}
>
> Why? Only one argument to pass, and to pass on to successive calls. I
> see no downside.
Sounds good to me. I have
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 t
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 . p
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
print those.
>>>
>>> On the contrary, inside GHC I /do/ want to print them. Otherwise how can
>>> I see what the renamer has done?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Shayan Najd [mailto:sh.n
t;
>> Simon
>>
>>
>>
>> *From:* Shayan Najd [mailto:sh.n...@gmail.com]
>> *Sent:* 28 July 2017 12:20
>> *To:* Simon Peyton Jones
>> *Cc:* ghc-devs@haskell.org; Alan & Kim Zimmerman
>> *Subject:* Re: Operating on HsSyn
>>
>>
>
July 2017 12:20
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org; Alan & Kim Zimmerman
> *Subject:* Re: Operating on HsSyn
>
>
>
> Before all this, we may need to discuss a bit about the intended semantics
> of
>
> `Outputable`: does it need to print `Po
-devs@haskell.org; Alan & Kim Zimmerman
Subject: Re: Operating on HsSyn
Before all this, we may need to discuss a bit about the intended semantics of
`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`
suffixed constructors? If not, then we only need to write a set of inst
Before all this, we may need to discuss a bit about the intended semantics
of
`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`
suffixed constructors? If not, then we only need to write a set of
instances
for the base growable AST, once and for all. Such instances will be
Devs,
Shayan is working away on "Trees that grow"... do keep it on your radar:
To: ghc-devs
Sent: 25 May 2017 23:49
Do take a look at this:
* We propose to re-engineer HsSyn itself. This will touch a lot of
code.
* But it's very neat, and will bring big long-term advantages
11 matches
Mail list logo