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@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.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs