February 2018 - ghc-steering-committee

Type-level type applications (#80): Recommend accept
by Richard Eisenberg 01 Mar '18

01 Mar '18

This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80 <https://github.com/ghc-proposals/ghc-proposals/pull/80>) introduces type-level type applications, extending the existing TypeApplications syntax to work in types. - With -XTypeApplications, you will be able to instantiate kind variables in types. For example, you could talk about `Proxy @(Type -> Type) Maybe` and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE DoubleRep)`. And that's it! GHC *already* has the required/specified/inferred distinction in terms, which is unchanged in types. I believe strongly we should accept. There was no substantive dissenting commentary, just clarifying questions. Thanks, Richard

6 5

Please review: Int8/Word8, Shepherd: Simon Marlow
by Joachim Breitner 01 Mar '18

01 Mar '18

Dear Committee, this is your secretary speaking: Small types like `Int8#`/`Word8#` were proposed https://github.com/ghc-proposals/ghc-proposals/pull/74 I propose Simon Marlow 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 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/

8 8

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

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

23 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 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