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

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