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.zimm@gmail.com]
Sent: 13 November 2017 13:30
To: Simon Peyton Jones
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 mailto:simonpj@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.zimm@gmail.commailto:alan.zimm@gmail.com]
Sent: 13 November 2017 13:09
To: Simon Peyton Jones mailto:simonpj@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 mailto:simonpj@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.zimm@gmail.commailto:alan.zimm@gmail.com]
Sent: 13 November 2017 13:01
To: Simon Peyton Jones mailto:simonpj@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 mailto:simonpj@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.zimm@gmail.commailto:alan.zimm@gmail.com]
Sent: 13 November 2017 12:49
To: Simon Peyton Jones mailto:simonpj@microsoft.com>
Cc: ghc-devs@haskell.orgmailto: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
