RE: Operating on HsSyn

To: Simon Peyton Jones <simo...@microsoft.com> Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman <alan.z...@gmail.com>; Jacques Carette <care...@mcmaster.ca> Subject: Re: Operating on HsSyn On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the re

Re: Operating on HsSyn

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

Re: Operating on HsSyn

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

Re: Operating on HsSyn

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 > >

Re: Operating on HsSyn

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

the renamer has done? >> >> >> >> Simon >> >> >> >> *From:* Shayan Najd [mailto:sh.n...@gmail.com] >> *Sent:* 28 July 2017 12:20 >> *To:* Simon Peyton Jones <simo...@microsoft.com> >> *Cc:* ghc-devs@haskell.org; Alan &am

Re: Operating on HsSyn

mail.com] > *Sent:* 28 July 2017 12:20 > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Cc:* ghc-devs@haskell.org; Alan & Kim Zimmerman <alan.z...@gmail.com> > *Subject:* Re: Operating on HsSyn > > > > Before all this, we may need to discuss a bit

RE: Operating on HsSyn

imo...@microsoft.com> Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman <alan.z...@gmail.com> 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` suffi

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 instances for the base growable AST, once and for all. Such instances will

Operating on HsSyn

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