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

[Shayne Fletcher]

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* <https://digitalasset.com/>, creators of *DAML
<https://daml.com/>*

-- 
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 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190916/c4c11900/attachment.html>