How should we treat changes to the GHC API?

[Shayne Fletcher]

On Mon, Jul 27, 2020 at 5:24 PM John Ericson <john.ericson at obsidian.systems>
wrote:

>
> I think that basically exists:
> https://hackage.haskell.org/package/ghc-lib ? As permanent solution I
> don't like it, but as a stop gap to relieve any pressure for stability
> until we have sane interfaces, I *love* it.
>

`ghc-lib` is a literal subset of GHC files: `ghc-lib-parser` that set of
files sufficient to produce abstract syntax trees (~200 files), `ghc-lib`
the remaining set of files enabling Core generation from parsed syntax
trees (~300 of those) (more detail in the project README here
https://github.com/digital-asset/ghc-lib/blob/master/README.md).

There is at this time, no attempt to provide any additional interface,
"higher level" or otherwise, in these packages.

The key property of `ghc-lib-parser`/`ghc-lib` that makes them useful to
tool developers (e.g. HLint) is that they can utilize the GHC API without
being bound to a specific compiler version to do so.

-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200727/8c07b02d/attachment.html>