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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
