- ghc-steering-committee

Unlifted Newtypes (#98)
by Richard Eisenberg 28 Feb '18

28 Feb '18

I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98 Summary: This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns: - The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim. - The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes. - The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions. The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find. Opinion & recommendation: I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win. If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types. Thanks, Richard

6 6

Section numbering
by Simon Peyton Jones 27 Feb '18

27 Feb '18

Joachim I think it'd be super-helpful to number the sections of a GHC proposal. So much easier to navigate; and to refer to points in the discussion. It's easy: just add .. sectnum:: to the preamble. Could you do that to the template? But one other thing. If you look at https://github.com/Gertjan423/ghc-proposals/blob/quantified-constraints/pro… where I did that, you'll see that everything is under Section 1. better to give guidance about how to make a top-level heading that is just a heading, so only the other items have numbers. Otherwise every section numbers starts "1." which is silly. Thanks Simon

2 3

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] As-pattern synonyms (#94)
by Simon Peyton Jones 27 Feb '18

27 Feb '18

Joachim I’ve revised the as-pattern proposal and would like to submit it to the committee https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/AsP… Simon From: Joachim Breitner [mailto:notifications@github.com] Sent: 23 February 2018 15:14 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Mention <mention(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] As-pattern synonyms (#94) @simonpj<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, the discussion ebbed down. Do you want to submit it to the committee? Does the proposal need more work? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>.

1 0

Please Review: kind!!, Shepherd: Manuel Chakravarty
by Joachim Breitner 24 Feb '18

24 Feb '18

Dear Committee, this is your secretary speaking: the kind!! command ghci was proposed: https://github.com/ghc-proposals/ghc-proposals/pull/79 I propose Manuel as the shepherd, as he is the the only remaining committee member who is currently not shepherding anything(!). Manuel, 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: Type-level type applications, Shepherd: Richard
by Joachim Breitner 24 Feb '18

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

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

24 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 23 Feb '18

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

23 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 22 Feb '18

22 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