Trees that Grow and constraints

[Simon Peyton Jones]

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 at gmail.com]
Sent: 13 November 2017 13:30
To: Simon Peyton Jones <simonpj at 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 <simonpj at microsoft.com<mailto:simonpj at 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 at gmail.com<mailto:alan.zimm at gmail.com>]
Sent: 13 November 2017 13:09

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171113/28b7af0a/attachment-0001.html>