How should we treat changes to the GHC API?

[Neil Mitchell]

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 <daniel.trstenjak at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200728/b4ab04ff/attachment.html>