How should we treat changes to the GHC API?

[Richard Eisenberg]

> On Jul 27, 2020, at 2:07 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> a stronger focus on API stability and perhaps a broader view of what constitutes (or should be included in) the public-facing API would be welcome!

I agree with this in the abstract, but I'm not sure about agreeing with it in the concrete. (I don't mean to pick on Eric here -- but this was a nice sentence I could quote.) The problem is that stability in the API has a very real cost. It means that GHC developers maintain some interface indefinitely, even if the implementation drifts in a different direction. Folks doing the internal GHC work often don't have extensive experience with the API, which means that a move toward API stability would mean that GHC devs would be poorly equipped to decide when an interface is important to preserve or unimportant. This leads to the possibility that devs would spend a lot of time maintaining particular behavior that is not needed. And, of course, time spent holding the API stable is time not spent doing other tasks, and thus a move toward stability would slow down development. This might be a small difference -- I'm not predicting calamity -- but it's a real cost.

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.

To be clear: I'm not against API stability, but I do want to make clear that this choice has a cost.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200727/9e4c98e2/attachment.html>