- ghc-steering-committee

Please review: Mutable constructor fields, Shepherd: Ryan Newton
by Joachim Breitner 08 May '18

08 May '18

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/8 was brought before the committee, by our own Simon Marlow. I propose Ryan Newton as the Shepherd, because he asked for it :-) Ryan, 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. Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 18

Please Review: Kinds Without Promotion, Shepherd: Ryan Newton
by Joachim Breitner 05 May '18

05 May '18

Dear Committee, this is your secretary speaking: Kinds Without Promotion by Yavor https://github.com/ghc-proposals/ghc-proposals/pull/106 I propose Ryan Newton as the shepherd. Ryan, 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 -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Please Review: Top-level kind signatures, Shepherd: Roman Leshchinskiy
by Joachim Breitner 05 May '18

05 May '18

Dear Committee, this is your secretary speaking: Top-level kind signatures by Richard has been proposed: https://github.com/ghc-proposals/ghc-proposals/pull/54 I propose Roman Leshchinskiy as the shepherd, who is already shepherding the closely related proposal #81. 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 1

Committee Discussion : Lazy unboxed tuples
by Ryan Newton 05 May '18

05 May '18

Dear Committee, The public discussion <https://github.com/ghc-proposals/ghc-proposals/pull/35> for this one <https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/p…> has happened, now for 4 weeks of committee discussion and final accept/reject. In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). Richard, one bit that threw me off was this: *"we should require the bang even on bare variables, but that would break a lot of code I think."* Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. Discuss? -Ryan On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner <mail(a)joachim-breitner.de > wrote: > Hi, > > it is by Richard, I just got the URL wrong. The right pull request is > https://github.com/ghc-proposals/ghc-proposals/pull/35 > sorry for that. > > Using this thread is fine. > > Joachim > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > > Just to clarify, this is proposed by a user "winterland". I.e. not > > Richard, right? In the process document it is the author that "brings > > it before the committee" correct? > > > > I checked and it looks like our process document does not specify the > > means of our committee discussion. I propose we discuss this one > > right here on this thread, which we've already got sitting in our > > inboxes. > > > > Best, > > -Ryan > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner <mail@joachim-breit > > ner.de> wrote: > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > > was brought before the committee, by our own Richard. > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > > properly. > > > > > > Ryan, 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. > > > > > > > > > Greetings, > > > Joachim > > > > > > > > > -- > > > Joachim Breitner > > > mail(a)joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata(a)debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >

5 6

Please Review: Array resizing primitives (#121), Shepherd: Simon Marlow
by Joachim Breitner 01 May '18

01 May '18

Dear Committee, this is your secretary speaking: Array resizing primitives have been proposed by David Feuer: https://github.com/ghc-proposals/ghc-proposals/pull/121 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, in a new e-mail thread with the proposal number in the subject, 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

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Manuel M T Chakravarty 30 Apr '18

30 Apr '18

I assume, you meant to send this to ghc-steering-committee(a)haskell.org (in CC now) and not to the dev list. Manuel > 01.05.2018 02:12 Iavor Diatchki <iavor.diatchki(a)gmail.com>: > > Hello, > > As a shepherd for proposal #99, I'd like to kick off the discussion. The full proposal is available here: https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo… <https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo…> > > Summary: allows programmers to write `forall {x}` instead of `forall x` in type signatures. The meaning of the braces is that this parameter cannot be instantiated with an explicit type application and will always be inferred. The motivation is to shorten explicit type applications by skipping parameters that are known to be inferable, the common example being omitting the kinds in signatures with poly kinds. > > As I understand it, the main motivation for this proposals is to give programmers more flexibility when instantiating type variables, with a less noisy syntax. While the proposed solution might work in some situations, I am unconvinced that it is the best way to address the issue in general, for the following reasons: > > 1. It requires that programmers commit at declaration time about which arguments will be inferred, and which may be inferred or specified. While in some cases this may be an easy decision to make, in many cases this really is a decision which should be made at the use site of a function (e.g., I'd like to provide argument X, but would like GHC to infer argument Y). > > 2. It still requires that programmers instantiate arguments in a fixed order, which is sometimes dictated by the structure of the type itslef. Here is, for example, what the proposal suggests to do if you want to provide type before a kind: > > typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a > > While technically this is not wrong, it is not exactly elegant. > > I think that we should reject this proposal, and try to come up with a more comprehensive solution to the problem. > > One alternative design is to allow programmers to instantiate type variables by name. This is much more flexible as it allows programmers to instantiate whichever variables they want, and in whatever order. We've been doing this in Cryptol for a long time, and it seems to work really well. > > -Iavor > > > > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Please Review: ExtraCommas (#87), Shepherd: Chris Allen
by Joachim Breitner 30 Apr '18

30 Apr '18

Dear Committee, this is your secretary speaking: ExtraCommas has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/112 I propose Chris Allen as the shepherd. Chris, 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 with the proposal number in the subject, 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/

3 2

Please Review: UnliftedArray# (#112), Shepherd: Simon Marlow
by Joachim Breitner 28 Apr '18

28 Apr '18

Dear Committee, this is your secretary speaking: UnliftedArray# has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/112 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, in a new e-mail thread with the proposal number in the subject, 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

Status
by Joachim Breitner 25 Apr '18

25 Apr '18

Hi committee, the proposal process has become pretty popular, and it seems we are having trouble keeping up. There are a few proposals that needs shepherding … so please check if you are expected to make a recommendation or, if you have, if the discussion needs more guidance or can be closed. Since the last status update, we * were asked to review these proposals: - Provenance-Qualified Package Imports (Shepherd: Ben) - Quantified Constraints (Shepherd: Richard) - Kinds Without Promotion (Shepherd: Ryan) - DH quantifiers (Shepherd: me) - Top-level kind signatures (Shepherd: Roman) - Resurrect PatternSignatures (Shepherd: Chis) - forall {k} (Shepherd: Iavor) * got a recommendation from shepherds about: - :kind!! (accept) - Treat kind and type vars identically with `forall` (accept) - Binding existential type variables (reject) - Quantified Constraints (accept) * decided about the following proposals - :kind!! (needs revision) - Quantified Constraints (accept) - Source plugins (accept) - plugin recompilation avoidance (accepted, but proposal needs to be updated) - DH quantifiers (punted, now dormant) We currently have to act on the following 14 proposals, which is 2 more than a the time of the last the last status mail. Deriving Via https://github.com/ghc-proposals/ghc-proposals/pull/120 Shepherd: Joachim Status: Acceptance recommended Resurrect PatternSignatures https://github.com/ghc-proposals/ghc-proposals/pull/119 Shepherd: Chris Status: Waiting for recommendation. Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Waiting for recommendation. Define Kinds Without Promotion https://github.com/ghc-proposals/ghc-proposals/pull/106 Shepherd: Ryan Status: Waiting for recommendation. kind and type vars https://github.com/ghc-proposals/ghc-proposals/pull/103 Shepherd: SPJ Status: Discussion ongoing forall {x}, https://github.com/ghc-proposals/ghc-proposals/pull/99 Shepherd: Iavor Status: Waiting for recommendation. Binding existential variables https://github.com/ghc-proposals/ghc-proposals/pull/96 Shepherd: Roman Status: Roman recommends to reject. Very active discussion going on, with an alternative proposal in #126. Embrace Type-In-Type https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Status: We made progress. Iavor, Richard, do we have consensus now? Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: With #102 punted, discussion can and should start again. Top-level kinds signatures https://github.com/ghc-proposals/ghc-proposals/pull/54 Shepherd: Roman Leshchinskiy Status: Waiting for recommendation. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Status: This is lingering since last July! 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: Inconclusive discussion that fell silent, but not the clear consensus that I’d like. Ryan, what is the status here? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 15

Proposal: Embrace Type in Type
by Iavor Diatchki 25 Apr '18

25 Apr '18

Hello, I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83) and so I'd like to hear your thoughts about the proposal. In short, the proposal has two parts: 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`. 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`. At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail. As such, I think I would be OK with part 2. In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing. Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`. Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it. In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated. Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer. It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online. So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change. The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function. I am even less keen about this option, as I think it is better to pick a single notation and stick with it. I'd love to hear what others think! -Iavor

7 36