Trees that Grow and constraints

[Alan & Kim Zimmerman]

Will do

Alan

On 13 November 2017 at 19:08, Simon Peyton Jones <simonpj at microsoft.com>
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: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>
> 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]
> *Sent:* 13 November 2017 13:09
>
>
> *To:* Simon Peyton Jones <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>
> 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]
> *Sent:* 13 November 2017 13:01
> *To:* Simon Peyton Jones <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>
> 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]
> *Sent:* 13 November 2017 12:49
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* 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/d3d67f26/attachment.html>