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. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Ben Gamari | Sent: 06 February 2018 02:30 | To: Joachim Breitner ; ghc-steering- | committee@haskell.org | Subject: Re: [ghc-steering-committee] Do we consider the GHC API in | scope? | | Joachim Breitner writes: | | > Hi, | > | > in | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | > b.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F108&data=02%7C01%7Csimo | > | npj%40microsoft.com%7C45d9aac776734af02fe208d56d09967f%7Cee3303d7fb734 | b0c8589bcd847f1c277%7C1%7C0%7C636534810305126138&sdata=%2FlGFjPJMUrdqG | 3Cx1mJ7Rq%2FGoq8NVnY3SEn843dIFWQ%3D&reserved=0 David proposed changes | to the plugin API. The propsosal is still under discussion (so if you | want to comment, do it there), but more generally, I wonder: | > | > Is the GHC API (including the one for plugins) in scope for the GHC | > steering committee? | > | I'm very much on the fence about this, despite being the one who | initially referred the issue. It's not clear to me that making | interface decisions about the GhcPlugins or GHC modules is a task | well-suited to a committee. | | Regardless, I think having a relatively high-visibility place to | discuss changes like the plugins proposal is quite helpful. So, even | if we decide that the API is out-of-scope for the committee, I think | it may still be helpful to use the proposal forum to solicit community | feedback. While in principle this discussion could happen just as | easily on Trac, my impression is that GitHub has been a bit more | effective in collecting a wide range of input. | | Cheers, | | - Ben

| 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. Yes I agree. We should also allow that others may propose changes to (including new functions) in the GHC API; essentially feature requests. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 06 February 2018 13:57 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Do we consider the GHC API in | scope? | | 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://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2Fsrc%2FGHC.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf09432 | 3ae91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0% | 7C636535222689456123&sdata=dNSg4tkhR1JYxqMVHItcFImJtAnTFgklQZKpslI4gus | %3D&reserved=0 | | 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://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2FPlugins.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf094323a | e91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C | 636535222689456123&sdata=Ep2gyYuGnaRnmySNCeSqLlPVrNSivvgMIC%2FN85GyOn0 | %3D&reserved=0 | and/or | https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2FGhcPlugins.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0943 | 23ae91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0 | %7C636535222689466131&sdata=D2gK4lk%2F5oOXtUhPfbDsHDXWo17juAEioTK8r1mG | 0d8%3D&reserved=0 | 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/0e022e56b130ab9d277965b794e | 70d8d3fb29533 | 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 | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf094323ae91d48 | 6011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535 | 222689466131&sdata=YQaXg%2F7F9OL01FkHbzkgY9Cy2DVEAlQBUAee65Kt3lk%3D&re | served=0

Hi, Am Montag, den 12.02.2018, 17:29 +0000 schrieb Iavor Diatchki:

Until that day though, I like Joachim's phrasing.

added the wording to the README at https://github.com/ghc-proposals/ghc-proposals Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/