How should we treat changes to the GHC API?
Daniel Trstenjak
daniel.trstenjak at gmail.com
Tue Jul 28 06:37:46 UTC 2020
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
More information about the ghc-devs
mailing list