Re: Trees that Grow and constraints

I have updated the page, with a bit more detail and an additional plan > OK. It’s hard to keep this straight in email. Take a look at >> >> https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances >> >> >> >> Please edit and improve it. >> >> Alan

Re: Trees that Grow and constraints

Will do Alan On 13 November 2017 at 19:08, Simon Peyton Jones wrote: > Alan (adding Shayan and ghc-devs) > > > > OK. It’s hard to keep this straight in email. Take a look at > > https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances > > > > Please

RE: Trees that Grow and constraints

Alan (adding Shayan and ghc-devs) OK. It’s hard to keep this straight in email. Take a look at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances Please edit and improve it. Simon From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 13 November 2017 13:30 To:

Re: Trees that Grow and constraints

Isn't the solution always if generic programming makes things complicated, avoid it! Here generic programming is where you define instances parametric on the phase index. Why not defining three instances of the type class, one per each phase? Yes, we get code duplication (which in this case is

Re: Dynamically choosing the main function

On Mon, Nov 13, 2017 at 2:46 AM, Harendra Kumar wrote: > Also, the symbols are anyway exposed to the users, we just ask the users > to not look at those. > Only if you built a dynamic executable, or built for debugging. Default static executables are stripped. --

Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)

Manuel M T Chakravarty writes: >> I noted this on D4177 and discussed the effect with Alan. Indeed there is >> quite a sizeable regression in compilation time but thankfully this is not >> because GHC itself is slower. Rather, it simply requires more work to >> compile.

Re: Trees that Grow and constraints

Just to clarify, this example is a simplification, in practice we would be applying different type for each type instance e.g. type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder type instance XEOverLit (GhcPass 'Typechecked)

Re: Trees that Grow and constraints

> So why not use one? > > > > Simon > > If I do instance (Data p) => Data (Experiment p) then GHC does not know that the type instances for type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder type instance

RE: Trees that Grow and constraints

Where specifying the type instance with a wild card keeps GHC happy (the XXOverLit case), but specifying for each of the three constructors for pass does not (the XEOverLit case) Well, of course! The derived data instance looks something like instance (Data (GhcPass p)) => Data (Experiment

Re: Trees that Grow and constraints

And it seems that -- data Experiment p = Experiment { e_ext :: (XEOverLit p), e_val :: Int } | XExperiment (XXOverLit p) deriving instance (Data GhcPs) => Data (Experiment GhcPs) deriving instance (Data GhcRn) => Data (Experiment GhcRn) deriving

Trees that Grow and constraints

At the moment the Trees that Grow implementation in GHC master makes use of massive constraint types to provide Data instances for the hsSyn AST. I am trying to remove the need for this, and have hit a problem. The example I have reduced it to is here [1] The essence of the problem is