How should we treat changes to the GHC API?

[John Ericson]

On 7/27/20 4:57 PM, Richard Eisenberg wrote
> On the other hand, we could imagine a dedicated GHC API volunteer who 
> maintains the API on top of the shifting sands of GHC. Having a 
> central project to deal with the API would satisfy clients by 
> projecting a stable interface, and it wouldn't hinder GHC development, 
> as the API volunteer would take on the compatibility burden. Of 
> course, success here would require a dedicated, competent volunteer.

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.

John