<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 27, 2020, at 2:07 PM, Eric Seidel <<a href="mailto:eric@seidel.io" class="">eric@seidel.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">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!</span></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">To be clear: I'm not against API stability, but I do want to make clear that this choice has a cost.</div><div class=""><br class=""></div><div class="">Richard</div></body></html>