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/... 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/Plug... and/or https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/GhcP... 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/0e022e56b130ab9d277965b794e70d8d3... 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/