- ghc-steering-committee

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

11 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 08 Feb '18

08 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

Deadlines for Shepherds?
by Joachim Breitner 08 Jan '18

08 Jan '18

Hi, you know that I like slim smooth processes with not too many rules, and our current process worked pretty nicely for the first few proposals. But now it seems that we lost some steam, and a fair number of proposals are stuck waiting for their Shepherd to make progress. Does this mean that people simply need deadlines for work to be done? Do you want deadlines? Also, I am happy to re-assign some stalled proposals to new shepherds. Does anyone want to volunteer recommending a decision for one or more of these proposals: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3

Status
by Joachim Breitner 05 Jan '18

05 Jan '18

Dear Committee, welcome to the new year 2018. Since the last status update, we * were asked to review these proposals: - merge -XTypeInType * accepted the following proposals: - /none/ * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Committee deliberation ongoing, likely expecting changes. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Roman suggested changes, a slow discussion is happening. Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Shepherd: Simon Marlow Status: Waiting for Simon to make a recommendation Embrace (Type :: Type) https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Diatchki Status: Waiting for Iavor to make a recommendation 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… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 06 Dec '17

06 Dec '17

Dear Commmittteee, Since the last status update, we * were asked to review these proposals: - visible dependent quantification - Deprecate STM invariant mechanism - add incomplete-uni-patterns and incomplete-record-updates to -Wall - Block arguments * accepted the following proposals: - underscores in literals - Block arguments * sent the following proposals back for further refinement - /none/ * rejected the following proposals: - /none/ * Had a discussion how to scale the committee process to “big” proposals like linear types. On our table at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Manuel suggests acceptance, committee deliberation ongoing Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Waiting for Roman to make a recommendation Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation -Wall to include incomplete-uni-patterns and incomplete-record-updates https://github.com/ghc-proposals/ghc-proposals/pull/71 Shepherd: Simon Marlow Status: Waiting for Simon to make a recommendation Dear shepherds, there is work waiting for you! 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… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Underscores in literals
by Iavor Diatchki 06 Dec '17

06 Dec '17

Hello, This e-mail is about pull request #76, to allow underscores in numeric literals: https://github.com/takenobu-hs/ghc-proposals/blob/numeric-underscores/propo… In short, this is a very simply feature, which modifies the notation for numeric literals to allow writing underscores (_) in the middle of literals. The underscores are only to increase readability, and have no effect on the meaning of the program. So, for example, I could write things like: 10_000_072 or 0xFFFF_FA10. Many other languages have a similar feature (especially hardware specification languages) and I see no downsides to it, so I think we should accept it. Please respond to this e-mail if you have objections. Cheers, -Iavor

5 6

Proposal: BlockArguments (Shepherd: Joachim)
by Joachim Breitner 06 Dec '17

06 Dec '17

Dear committee, the BlockArguments (former ArgumentDo) proposal was brought before us: https://github.com/ghc-proposals/ghc-proposals/pull/90 I’ll shepherd this myself. The idea is to not require parenthesis around block syntax elements such as lambda expressions, let bindings, if-then-else, case-of and (in particular) do expressions. The change to the grammar to enable that is actually a simplificiation (it removes one non-terminal, lexp). Variants proposed are: * do this only for `do` in argument position, or * do it for all blocks, but only in function argument positions. I am fond of this proposal, because it allows code with less parenthesis to be written. If Haskell was written from ground up, I believe there would be little opposition to this setup, and maybe we would not have had to hack higher-rank support into ($), as the idiom `runST $ do …` would just be `runST do …`. Another argument in favor of it is the mentioned simplificiation of the grammar rules. I am aware that reading the parenthesis-free code feels strange to many, but I not overly worried about that: Every change feels strange, and in this case, only code that is otherwise illegal is affected. Akio has indicated that he is willing to work on the implementation. Therefore, I suggest that we accept this proposal. Please discuss (or voice you silent agreement). Regards, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5

What do we need from the linear-types proposal?
by Joachim Breitner 29 Nov '17

29 Nov '17

Dear committee, Mathieu Boespflug asks on https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-3471232… > Could the Committee define the items it expects before it can make a > determination about this proposal? We've heard in this thread members > of the Committee ask for a fleshed out linear base, more examples > than are already in the proposal and in the paper, and also full code > from other users at large. I can certainly understand where they are > coming from. But at the same time, I am concerned about scope creep. > Defining where the goal posts are from now would certainly help. and I am not sure what to reply here… but “we’ll know that once we made a determination” is probably not helpful. Does anyone here feel like he could define the requirements that are necessary to allow us to consider the proposal properly? Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 7

Please review: add incomplete-uni-patterns and incomplete-record-updates to -Wall, Shepherd: Simon Marlow
by Joachim Breitner 21 Nov '17

21 Nov '17

Dear Committee, this is your secretary speaking: The question of whether the meaning of -Wall out to include incomplete- uni-patterns and incomplete-record-updates was brought before the committee. https://github.com/ghc-proposals/ghc-proposals/pull/71 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/

1 0