Re: Changes in GHC API modularity with the "Encode shape information in PMOracle" MR

[Shayne Fletcher via ghc-devs]

Hi Sebastian,

On Mon, Sep 16, 2019 at 5:23 PM Sebastian Graf  wrote:

> Hi Shayne,
>
> Sorry to hear that! We didn't consider modularity at all and I would be
> happy to try to refactor in a way that would allow `ghc-lib-parser` to be
> properly separated again.
> I'm fairly certain that I didn't directly touch anything parser related,
> but apparently the new cyclic import of PmOracle within TcRnTypes (which is
> also exposed from `ghc-lib-parser`) pulled in the other half of GHC.
> I'll see if I can fix that tomorrow, if only by extracting a separate
> `Types`-style module.
>
>
That sounds awesome. Tremendous. Thank-you! Please feel free to reach out
to me if there's anything I can do to help your analysis[*]!

[*] For the record, the procedure for calculating the `ghc-lib-parser`
modules is a little complicated by there needing to be some generated
equivalents of `.hsc` files present for this to work but the procedure is
at the end of the day just `ghc -M` invoked over `Parser.hs`.


> Cheers,
> Sebastian
>

Fingers crossed and all the best!

-- 
*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* , creators of *DAML
*

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
. If you are not the 
intended recipient, please delete this message.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Changes in GHC API modularity with the "Encode shape information in PMOracle" MR

[Sebastian Graf]

Hi Shayne,

Sorry to hear that! We didn't consider modularity at all and I would be
happy to try to refactor in a way that would allow `ghc-lib-parser` to be
properly separated again.
I'm fairly certain that I didn't directly touch anything parser related,
but apparently the new cyclic import of PmOracle within TcRnTypes (which is
also exposed from `ghc-lib-parser`) pulled in the other half of GHC.
I'll see if I can fix that tomorrow, if only by extracting a separate
`Types`-style module.

Cheers,
Sebastian

Am Mo., 16. Sept. 2019 um 22:04 Uhr schrieb Shayne Fletcher via ghc-devs <
ghc-devs@haskell.org>:

> Some time back, the `ghc-lib` project split into two targets :
> `ghc-lib-parser` for those projects that just need to produce syntax trees
> and `ghc-lib` (re-exporting `ghc-lib-parser` modules) having the remaining
> modules for projects that need to go on and distill parse trees to Core.
> The idea of course was to reduce build times for tools like hlint that only
> need parse trees.
>
> Roughly, `ghc-lib-parser` got about 200 files and `ghc-lib` 300. Today
> after landing `7915afc6bb9539a4534db99aeb6616a6d145918a`, "Encode shape
> information in `PmOracle`", `ghc-lib-parser` now needs 543 files and
> `ghc-lib` gets just 25.
>
> That may be just bad luck for `ghc-lib-parser` and the way it has to be
> but I thought I should at least mention the knock-on effect of this change
> on the modularity of the GHC API in case this consequence hasn't been
> considered?
>
> --
> *Shayne Fletcher*
> Language Engineer */* +1 917 699 7663
> *Digital Asset* , creators of *DAML
> *
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
> intended recipient, please delete this message.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: eqType modulo associated types?

[Sebastian Graf]

Hi Conal,

I've had success with `FamInstEnv.topNormaliseType` in the past. `eqType`
doesn't take `FamInstEnvs`, so I'm pretty sure it can't look through family
instances by itself.

Cheers,
Sebastian

Am Mo., 16. Sept. 2019 um 02:38 Uhr schrieb Conal Elliott :

> It looks to me like `eqType` accounts for type synonyms but not associated
> types. Is there a variant that compares modulo associated types, or perhaps
> a type normalizing operation to apply before `eqType`?
>
> Thanks, - Conal
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs