- ghc-steering-committee

Status
by Joachim Breitner 18 Mar '18

18 Mar '18

Hi, I hope you all survived the ICFP deadline well, and surely you are now all eager to work off the pretty long list of proposals that are before us. Since the last status update, we * were asked to review these proposals: - kind and type vars in forall (Shepherd: SPJ) - Source Plugins (Shepherd: Chris Allen) - Constraint vs. Type (Shepherd: SPJ) - Type-level type app (Shepherd: Richard) - kind!! (Shepherd: Manuel) - as-patterns (Shepherd: me) - scoped type vars (Shepherd: Roman) - or-patterns (Shepherd: Manuel) * got a recommendation from shepherds about: - Int8/Word8 (accept) - DH quantifiers (accept) - Type-level type app (accept) - Constraint vs. Type (accept) - as-patterns (accept) * decided about the following proposals - unlifted newtypes (accept) - Int8/Word8 (accept) - type level app (accept) - as-patterns (accept) Plenty of work to do, as we currently have to act on the following 12 proposals! Plugin recompilation API https://github.com/ghc-proposals/ghc-proposals/pull/108 Shepherd: Ben, recommends acceptance Status: Ongoing discussion, with me solitarily holding up the process with criticism Source Plugins https://github.com/ghc-proposals/ghc-proposals/pull/107 Shepherd: Chris Allen Status: Waiting for Allen’s recommendation kind and type vars https://github.com/ghc-proposals/ghc-proposals/pull/103 Shepherd: SPJ Status: Waiting for Simon to make a recommendation Dependent Haskell quantifier syntax https://github.com/ghc-proposals/ghc-proposals/pull/102 Shepherd: Joachim, recommends acceptance Status: Reservations from SPJ and Iavor, no consensus emerging so far. Binding existential variables https://github.com/ghc-proposals/ghc-proposals/pull/96 Shepherd: Roman Status: Waiting for Roman to make a recommendation Embrace Type-In-Type https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Status: Ongoing discussion, mostly about the fate of * Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Unclear. Blocked on #102? :kind!! https://github.com/ghc-proposals/ghc-proposals/pull/79 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Constraint vs. Type https://github.com/ghc-proposals/ghc-proposals/pull/32 Shepherd: Simon PJS (proposed acceptance) Status: Simon’s proposal was met with silence. Ergo accept? Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: There was more discussion. Does this need to go back to the discussion phase? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please Review: Or patterns, Shepherd: Manuel
by Joachim Breitner 03 Mar '18

03 Mar '18

Dear Committee, this is your secretary speaking: Or patterns were proposed by Ömer https://github.com/ghc-proposals/ghc-proposals/pull/43 I propose Manuel Chakravarty as the shepherd. 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

Plugin recompilation avoidance
by Ben Gamari 02 Mar '18

02 Mar '18

Hi everyone, I'm writing you in reference to GHC Proposal #108 [1], which introduces a mechanism allowing plugins greater control over GHC's recompilation behavior. The committee is currently considering this proposal for acceptance and while most of you have already expressed general support for the proposal during the discussion period, we wanted to check once more with you to ensure that no issues have gone unnoticed. If any of you have any final thoughts regarding the proposal, do let us know in the next few days. Otherwise we will accept the proposal as-is. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/108

2 1

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

Please Review: Scoped Type variables for existentials, Shepherd: Roman
by Joachim Breitner 01 Mar '18

01 Mar '18

Dear Committee, this is your secretary speaking: Scoped Type variables for existentials by Emmanuel “Emma” Suarez, with help from Richard Eisenberg and Stephanie Weirich. https://github.com/ghc-proposals/ghc-proposals/pull/96 I propose Roman Leshchinskiy as the shepherd. Roman, 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

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