- ghc-steering-committee

Please Review: Type-level type applications, Shepherd: Richard
by Joachim Breitner 23 Feb '18

23 Feb '18

Dear Committee, this is your secretary speaking: Type-level type applications were proposed https://github.com/ghc-proposals/ghc-proposals/pull/80 I propose Richard as the shepherd, as this is clearly up his allay. Richard, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please Review: Constraint = Type, Shepherd: Simon PJ
by Joachim Breitner 23 Feb '18

23 Feb '18

Dear Committee, this is your secretary speaking: Constraint = Type was proposed, by Richard https://github.com/ghc-proposals/ghc-proposals/pull/32 I propose Simon PJ as the shepherd, as he – as far as I know – already had a close look. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

GHC proposal process: merging and closing
by Spiwack, Arnaud 23 Feb '18

23 Feb '18

Dear all, Joachim directed me here to raise some remarks about the proposal process that I've brought up. Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged. On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope. Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features. >From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it. On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent. I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed. What does everybody think? [1] https://github.com/ghc-proposals/ghc-proposals/pull/5 Best, Arnaud Spiwack

5 8

Please Review: Source Plugins, Shepherd: Chistopher
by Joachim Breitner 22 Feb '18

22 Feb '18

Dear Committee, this is your secretary speaking: Source Plugins were proposed https://github.com/ghc-proposals/ghc-proposals/pull/107 I propose Christopher Allen as the Shepherd. Christopher, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please Review: kind and type vars in forall, Shepherd: Simon PJ
by Joachim Breitner 22 Feb '18

22 Feb '18

Dear Committee, this is your secretary speaking: Treating kind and type vars the same in forall was proposed: https://github.com/ghc-proposals/ghc-proposals/pull/103 I propose Simon PJ as the Shepherd. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Steering committee discussions
by Simon Peyton Jones 21 Feb '18

21 Feb '18

Friend on the GHC proposals steering committee I think it is helpful to have our shepherding process to drive debate to a conclusion. But I think we are losing value by holding technical discussions on the email list, rather than on the proposal's own thread. I'm not sure if the steering committee email list is visible to all; but even if it is, the info on a particular proposal is harder to find. The thread below is a case in point. Good stuff from Joachim, but not visible to the author or the world; result, lost insights. Suggestion: could we hold all the committee debase on the proposal thread, thereby allowing the author to chime in if need be? There might be some messages we want to be private -- very well, use the email list for those, but my sense is that 95% are absolutely publishable. What changes when the shepherd kicks in? Answer: the committee switches from observer (and contribute if you like) mode, to obligation-to-consider mode. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces(a)haskell.org] On Behalf Of Joachim Breitner | Sent: 20 February 2018 03:37 | To: ghc-steering-committee(a)haskell.org | Subject: Re: [ghc-steering-committee] Plugin recompilation avoidance | interface (#108) | | Hi Ben, | | thanks for kicking this off. | | Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari: | > The proposal addresses a long-standing limitation (#7414) of the GHC | > plugin interface which has become increasingly visible to users in | > recent years. While the particular approach proposed breaks existing | > plugin users, it is expressive enough to allow GHC to perform more | > aggressive recompilation avoidance in the future [1]. Moreover, the | > smart constructors proposed should make for a reasonably smooth | > migration path. | > | > Given that the plugins appears to have buy-in from a few notable | > plugin authors, I recommend that we accept this proposal. | | How realistic is it to do the partial module recompilation thing that | warrants multiple PluginRecompile values per module? For this to be | useful the compiler would have to | | * calculate the typechecker plugin’s hash for module M | * notice that it has changed, and start compiling M | * but then, when we have core, magically notice that the output of | the | desugarer has not changed, and consider to abort calculation | * but then notice that a core2core plugin was involved, and ask that | for the new hash | * and then this hash must be unchanged | * and then really the compilation has ended. | | Is that realistic? Can someone fill this example with concrete life? | | Maybe I am just not seeing what people have in mind – but I feel | unless this really is more than a very vague idea, we should consider | the simpler variant where each plugin gets to calculate a single hash | per module – and not possibly many in various stages. | | Another way of putting it: The compiler pipeline is (simplified) | | 1. decide what to compiler | 2. parse | 3. typecheck | 4. desguar | 5. optimize | 6. code gen | | Plugins so far hook into step 3 and 5. Every one of these steps | probably eventually deserves a plugin hook. This proposal is about | adding one to step 1. With this view, I find the “add a single | function to Plugin”, as described in | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F108%23issuecomment- | 362671438&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b7e868 | c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654694617 | 3205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC | JBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=C4lfSbadTT23lvfARKolUVSPfPfJSt5PvqJDTvJfYFQ%3D&reserved=0 | much more convincing. | | Cheers, | Joachim | | | -- | Joachim “nomeata” Breitner | mail(a)joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b | 7e868c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636546 | 946173205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM | zIiLCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=w7Bv0He4imipDZAdnZhNc2EEwXCo7ejMNZ1o%2BGp7HWU%3D&reserved=0

5 7

Status
by Joachim Breitner 20 Feb '18

20 Feb '18

Cheers everyone, Since the last status update, we * were asked to review these proposals: - Int8#/Word8# - unlifted newtypes - plugin recompilation API * got a recommendation from shepherds about: - incomplete-uni-patterns (accept) - embrace Type in Type (recommendation is somewhat unclear) - Deprecate STM invariant (accept) - Unlifted newtypes (accept) - mutable constructor fields (accept) - plugin recompilation API (accept) * decided about the following proposals - Or patterns (sent back for refinement) - Deprecate STM invariant (accept) - incomplete-uni-patterns (accept) Good job, team! On our table at the moment are 7 proposals: Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Ryan recommends acceptance Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Discussion ebbed down. Do we have consensus? Embrace (Type :: Type) https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Diatchki Status: Iavor started a discussion Small primitive types https://github.com/ghc-proposals/ghc-proposals/pull/74 Shepherd: Simon Marlow Status: Waiting for Simon to make a recommenataion Unlifted Newtypes https://github.com/ghc-proposals/ghc-proposals/pull/98 Shepherd: Richard Eisenberg Status: Richard recommends acceptance Plugin recompilation avoidance https://github.com/ghc-proposals/ghc-proposals/pull/108 Shepherd: Ben Gamari Status: Ben suggests acceptance, but I am nitpicking Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review: plugin recompilation avoidance, Shepherd: Ben Gamari
by Joachim Breitner 14 Feb '18

14 Feb '18

Dear Committee, this is your secretary speaking: An API for deciding whether plugins should cause recompilation was proposed: https://github.com/ghc-proposals/ghc-proposals/pull/108 I propose Ben Gamari as the Shepherd. Ben, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Do we consider the GHC API in scope?
by Joachim Breitner 12 Feb '18

12 Feb '18

Hi, in https://github.com/ghc-proposals/ghc-proposals/pull/108 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? Or should they go the same route as other, genuinely internal changes in GHC, which would be Trac and Phab? Note that plugins often have to import arbitrary GHC modules, not just GhcPlugins, so really every exported function in GHC is part of the GHC API and hence the plugin API? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 7

Please review: unlifted newtypes, Shepherd: Richard Eisenberg
by Joachim Breitner 11 Feb '18

11 Feb '18

Dear Committee, this is your secretary speaking: Unlifted Newtypes were proposed https://github.com/ghc-proposals/ghc-proposals/pull/98 I propose Richard Eisenberg as the Shepherd. Richard, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1