Will do Alan
On 13 November 2017 at 19:08, Simon Peyton Jones <[email protected]> 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 edit and improve it. > > > > Simon > > > > > > *From:* Alan & Kim Zimmerman [mailto:[email protected]] > *Sent:* 13 November 2017 13:30 > > *To:* Simon Peyton Jones <[email protected]> > *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 witnesses] > > > > | XOverLit > > (XXOverLit p) > > deriving instance (DataIdLR p p) => Data (HsOverLit p) > > > > And in HsExtension.hs we have an ever-growing constraint type defining > DataIdLR > > I am trying to remove the need for that. > > In the Experiment.hs file, I found that using > > data Experiment p > = Experiment { > e_ext :: (XEOverLit p), > e_val :: Int } > | XExperiment (XXOverLit p) > deriving instance Data (GhcPass 'Parsed ) => Data (Experiment (GhcPass > 'Parsed )) > deriving instance Data (GhcPass 'Renamed ) => Data (Experiment (GhcPass > 'Renamed )) > deriving instance Data (GhcPass 'Typechecked) => Data (Experiment (GhcPass > 'Typechecked)) > > will compile using GHC 8.2.1, but not with GHC 8.0.2 > > > > Alan > > > > On 13 November 2017 at 15:13, Simon Peyton Jones <[email protected]> > wrote: > > And it looks like it could work, when bootstrapping from GHC 8.2.1, but > this is still a long time away. > > > > I’m sorry, I still don’t know what “it” is that “could work”. Can you be > more precise. I think you must be suggesting some alternative to my code > below? > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:[email protected]] > *Sent:* 13 November 2017 13:09 > > > *To:* Simon Peyton Jones <[email protected]> > *Subject:* Re: Trees that Grow and constraints > > > > Yes. > > > > If we can solve this, it means we can get rid of the DataId and ForallXXX > constraints defined in hsSyn/HsExtension.hs > > > > And also move the type family definitions to the files where they are used. > > > > I suspect that typechecking those constraint sets is adding to the GHC > compilation time, significantly > > > > And it looks like it could work, when bootstrapping from GHC 8.2.1, but > this is still a long time away. > > > > Alan > > > > On 13 November 2017 at 15:05, Simon Peyton Jones <[email protected]> > wrote: > > That’s not a problem you are trying to solve – it’s just some code 😊. > > > > Let me hazard a guess. You want a derived instance for > > > > Data (OverLit (GhcPass p)) > > > > But to do that of course we’ll need Data (XEOverLit (GhcPass p)). > > > > We can’t possibly have that at the time of writing the instance > declaration, because p is universally quantified. So we are stuck with > > > > instance (Data (XEOverLit (GhcPass p))) => Data (OverLit > (GhcPass p)) where… > > > > and the context gets a constraint for every extension field in OverLit, > which is painful. > > > > So we have a solution bit contexts, but it’s painful. > > > > Is that the problem you are trying to solve? > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:[email protected]] > *Sent:* 13 November 2017 13:01 > *To:* Simon Peyton Jones <[email protected]> > > *Subject:* Re: Trees that Grow and constraints > > > > Sorry, I simplified the problem. > > The actual one I am trying to solve will be the general case, so e.g. > > type instance XEOverLit (GhcPass 'Parsed ) = RdrName > type instance XEOverLit (GhcPass 'Renamed ) = Name > type instance XEOverLit (GhcPass 'Typechecked) = Id > > or more likely, modelling the existing PostTc and PostRn usages. > > And I suppose looking into using them in a single definition might work > > Alan > > > > > > On 13 November 2017 at 14:55, Simon Peyton Jones <[email protected]> > wrote: > > Or do I misunderstand your advice? > > > > Well, you said > > 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) > > My question is: why not just use the wildcard, in that case? > > Do you want to re-state the problem you are trying to solve? > > > > Simon > > > > > > *From:* Alan & Kim Zimmerman [mailto:[email protected]] > *Sent:* 13 November 2017 12:49 > *To:* Simon Peyton Jones <[email protected]> > *Cc:* [email protected] > *Subject:* 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 XEOverLit (GhcPass 'Typechecked) = PlaceHolder > > apply. > > > > Or do I misunderstand your advice? > > > > Alan > > > > > > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
