I don't think we should be overly controlling on this and lean towards being flexible with making changes in the source code as needed.   Overall my experience with the GHC API has been that it can be very handy, but I've never managed to get anything done by just sticking to the API proper---I inevitably end up using other "unofficial" modules from GHC, and I don't think it is reasonable to expect that none of those would change.    Long term, it would be nice to have a stable GHC API, but the actual API depends very much on what you are trying to do, so I can even imagine there being more than one API.  Until that day though, I like Joachim's phrasing.








On Tue, Feb 6, 2018 at 5:57 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

Am Dienstag, den 06.02.2018, 09:27 +0000 schrieb Simon Peyton Jones:
> I think we should cover GHC API changes.
>
> * The committee is meant to cover the "users-eye-view" of GHC.
>   The GHC API is a major asset, used by many users.  OK, so they
>   are nestling a bit closer to the implementation, but still.
>
> * There is no other forum to discuss API changes.
>
> * In principle a user of GHC-as-a-library can call any old internal
>   function; we should /not/ cover this.  Only the high-level
>   "advertised" API.
>
> * We don't do a good job of advertising that API; it's basically
>   what is exported by module GHC.  But I think it that proposals
>   focused on improving it would be quite helpful.

just for the reference, that would be this module:
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/src/GHC.html

So in particular, every change in HsSyn is no longer an internal change
under that view, as is any modification to DynFlags.

And I presume you’d include
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/Plugins.html
and/or
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/GhcPlugins.html
to be considered part of the API as well, right? But the latter re-
exports really many internal modules.

Under this rule, a change like
https://git.haskell.org/ghc.git/commitdiff/0e022e56b130ab9d277965b794e70d8d3fb29533
would have required committee approval?


I am worried about adding too much red tape to GHC development and
overloading the committee. How about this as a compromise:

    Changes to the GHC or Plugin API are not automatically within the
    scope of the committee, and can be contributed following the usual
    GHC workflow. Should the GHC maintainers deem a change significant
    or controversial enough to warrant that, they may, at their
    discretion, involve the committee and ask the contributor to write a
    formal proposal.

Cheers,
Joachim



--
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee