RE: Operating on HsSyn

2017-07-31 Thread Simon Peyton Jones via ghc-devs
: 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

Re: Operating on HsSyn

2017-07-30 Thread Shayan Najd
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

Re: Operating on HsSyn

2017-07-28 Thread 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 t

Re: Operating on HsSyn

2017-07-28 Thread Alan & Kim Zimmerman
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

Re: Operating on HsSyn

2017-07-28 Thread MarLinn
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

Re: Operating on HsSyn

2017-07-28 Thread Alan & Kim Zimmerman
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

Re: Operating on HsSyn

2017-07-28 Thread Shayan Najd
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 >> >> >

Re: Operating on HsSyn

2017-07-28 Thread Shayan Najd
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

RE: Operating on HsSyn

2017-07-28 Thread Simon Peyton Jones via ghc-devs
-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

Re: Operating on HsSyn

2017-07-28 Thread Shayan Najd
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

Operating on HsSyn

2017-07-28 Thread Simon Peyton Jones via ghc-devs
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