How should we treat changes to the GHC API?

[Eric Seidel]

Thanks Richard, you raise some important points. 

API stability does impose a real cost on developers (working at a company with a firm-wide integration build for the past three years has made me keenly aware of that). But API instability also imposes a real cost on clients.

I think there are a couple things that could be done though, to help lessen the burden, and to share it between devs and clients. One is to define a clear separation between the public API and internal modules. GHC does this to an extent, but as I mentioned earlier, I think it needs a more comprehensive public API (I did not mean that we should just declare more modules as part of the public API, but provide stable wrappers around that functionality). You’re right that GHC devs are not the best suited to define the public API, I think it should be done as a collaboration between clients and devs. 

Another option could be to have a transition period for APIs like we do for changes to the language. GHC already commits to waiting a few revisions to use new language features in the name of shortening bootstrapping chains, waiting a few revisions to drop an old API doesn’t feel all that different and would give clients a lot of breathing room. 

I don’t want to put the burden of API stability all on GHC devs either, but I do think it could probably be balanced better. And this is where having something like the Steering Committee could help. It doesn’t need to be as formal either, perhaps a small group of stakeholders that get tagged on MRs to the public API, or a mailing list where you solicit feedback. 

Sent from my iPhone

> On Jul 27, 2020, at 15:57, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> 
> 
>> 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/ec86aabb/attachment.html>