How should we treat changes to the GHC API?

Shayne Fletcher shayne.fletcher.50 at gmail.com
Tue Jul 28 10:11:03 UTC 2020


On Mon, Jul 27, 2020 at 7:13 PM Shayne Fletcher <
shayne.fletcher.50 at gmail.com> wrote:

>
>
> 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.
>
> [...]
>

I should mention that the related project `ghc-lib-parser-ex` (README here
https://github.com/shayne-fletcher/ghc-lib-parser-ex/blob/master/README.md)
IS in large part motivated by the need to provide stable interfaces over
`ghc-lib-parser`.

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


More information about the ghc-devs mailing list