Re: Trees that Grow and constraints

2017-11-13 Thread Alan & Kim Zimmerman
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

2017-11-13 Thread Alan & Kim Zimmerman
ow/Instances > > > > Please edit and improve it. > > > > Simon > > > > > > *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] > *Sent:* 13 November 2017 13:30 > > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Subject:*

RE: Trees that Grow and constraints

2017-11-13 Thread Simon Peyton Jones via ghc-devs
3:30 To: Simon Peyton Jones <simo...@microsoft.com> Subject: Re: Trees that Grow and constraints At the moment, in GHC master, we have data HsOverLit p = OverLit { ol_ext :: (XOverLit p), ol_val :: OverLitVal, ol_witness :: HsExpr p} -- Note [Overloaded literal

Re: Trees that Grow and constraints

2017-11-13 Thread Shayan Najd
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: Trees that Grow and constraints

2017-11-13 Thread Alan & Kim Zimmerman
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

2017-11-13 Thread Alan & Kim Zimmerman
> 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

2017-11-13 Thread Simon Peyton Jones via ghc-devs
lan & Kim Zimmerman Sent: 13 November 2017 09:24 To: ghc-devs@haskell.org Subject: 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 t

Re: Trees that Grow and constraints

2017-11-13 Thread Alan & Kim Zimmerman
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

2017-11-13 Thread Alan & Kim Zimmerman
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