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
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/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee