> On Jul 27, 2020, at 2:07 PM, Eric Seidel <e...@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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
