RE: How should we treat changes to the GHC API?

My real question is this: * Who “owns” (as in: takes responsibility for) the GHC API? If no person, or no group of people, feels responsible for it, it’ll just grow in a disorganised fashion, which is why we are where we are. This discussion thread has focused mainly on stability, but there is more to it than that. For example: * What kind of stability strikes a reasonable balance between developers and clients? Personally I think we should have * A public API that is pretty stable, plus * Access to many internal GHC functions that change quite a bit. Heavily used internal functions can get “blessed” and moved to the public API. Someone needs to do the blessing. * What is a good public API? Where is it written down? * What should GHC’s extensibility interface be like? Plugins and all that. What is a good design for (say) extensible interface files? What “hooks” should the GHC API afford? This is more than just “what arguments should this function take”… it’s a matter of fundamental design. But design questions like this belong in the GHC-API world (not the core GHC world) because they are all about extension points. * What is a good design for the plugins story more generally? I’d be quite content with a fairly informal group to act as the “owner”. But I think we would be better served if we had such a group, and knew who they were. Simon From: ghc-devs On Behalf Of Neil Mitchell Sent: 28 July 2020 09:19 To: GHC developers Subject: Re: How should we treat changes to the GHC API? The API changing regularly is a real hassle for people building on top of it. But, the people building on top of it are also some of the people changing it most. And the API isn't nice and beautiful as it stands, with lots of horrible work-arounds for downstream users. I'd suggest letting people change the API freely. But avoid making bikeshed API changes (those which are minor improvements at best, and really just a different flavour of the same). And perhaps loop in heavy API users when removing functionality. Thanks, Neil On Tue, Jul 28, 2020 at 7:38 AM Daniel Trstenjak mailto:daniel.trstenjak@gmail.com> wrote: On Mon, Jul 27, 2020 at 08:57:12PM +0000, 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.

Looking at other compilers that have been successful in having a stable API - like clang with the libclang - that's pretty much how they achieved it. The manpower of GHC devs is already pretty small, so putting another burden on them with a stable API won't work out that well. Also as a compiler dev you want to have the freedom to change your AST in the ways you need it, to incorporate new features. Having workarounds at this level to ensure API stability just seems to be the wrong place and will only increase the complexity in an already quite complex project. However a high level API on top of the AST is the perfect place for such special cases between different compiler versions. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C33d57a82355d47cff09b08d832ceec96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315211602862361&sdata=tzH8F0AkBGHuVc%2F1YYkzWV7Lxe0i%2FMWHoJw4Y8olBH8%3D&reserved=0