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: 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 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 <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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:alan.z...@gmail.com<mailto:alan.z...@gmail.com>] Sent: 13 November 2017 13:09 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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 <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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:alan.z...@gmail.com<mailto:alan.z...@gmail.com>] Sent: 13 November 2017 13:01 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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 <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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:alan.z...@gmail.com<mailto:alan.z...@gmail.com>] Sent: 13 November 2017 12:49 To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
