February 2018 - ghc-steering-committee

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 19 Feb '18

19 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 10 Feb '18

10 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

Please review: embrace Type::Type, Shepherd: Iavor
by Joachim Breitner 10 Feb '18

10 Feb '18

Dear Committee, this is your secretary speaking: Richards proposes to merge -XTypeInType into -XPolyKinds and -XDataKinds https://github.com/ghc-proposals/ghc-proposals/pull/83 I propose Yavor Diatchki as the Shepherd. Yavor, 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/

3 2

Proposal: accept "add incomplete-uni-patterns and incomplete-record-updates to -Wall"
by Simon Marlow 07 Feb '18

07 Feb '18

I propose that we accept the proposal add incomplete-uni-patterns and incomplete-record-updates to -Wall https://github.com/ghc-proposals/ghc-proposals/pull/71 <https://github.com/ghc-proposals/ghc-proposals/pull/71> Both warnings are avoidable and considered bad style, which makes them appropriate to include in -Wall. The reason that -Wincomplete-uni-patterns wasn't originally made part of -Wall was due to worries about noisiness ( https://ghc.haskell.org/trac/ghc/ticket/4905) but that's not a valid concern. -Wall is intentionally a moving target, if you want to stay Wall-clean you accept that new compiler releases may entail some work. Basically I think this is a no-brainer. Cheers Simon

5 4

Proposal #77 "Deprecating STM invariant mechanism" — suggesting acceptance
by Manuel M T Chakravarty 03 Feb '18

03 Feb '18

Folks, I’d like to reach consensus on Proposal #77 ”Deprecating STM invariant mechanism”: https://github.com/bgamari/ghc-proposals/blob/deprecate-stm-invariants/prop… (The discussion thread is at <https://github.com/ghc-proposals/ghc-proposals/pull/77>.) This proposal is about removing a rarely used feature that is arguably buggy and also imposes significant complexity. I think, removing ideas that turn out to be not working properly or simply aren’t sufficiently useful for the complexity they impose is an important part of the process. The STM invariant mechanism appears to fit that bill. Hence, I suggest to accept this proposal. Please let me know if you disagree; otherwise, I will assume tacit approval. Cheers, Manuel

4 3