Changes in GHC API modularity with the "Encode shape information in PMOracle" MR
shayne.fletcher at daml.com
Mon Sep 16 21:03:29 UTC 2019
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
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs