- ghc-steering-committee

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 22 Nov '17

22 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

Our process and BIG ideas
by Manuel M T Chakravarty 15 Nov '17

15 Nov '17

In the light of the linear types proposal PR, SimonPJ’s comment https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-3434578… and some uncertainty about the proposal process that has been communicated to me via a side channel, it might be worthwhile clarifying our expectations for large complex proposals. (I know, we basically punted on these questions in our initial discussion on the process with the intention to revisit after we gained some experience. It seems this time has come.) Firstly, we usually require proposals to be self-contained. This makes a lot of sense for small to medium-sized proposals to limit the time needed by the committee to hunt down all the required information. However, in a case, such as the linear types work, where there is a highly polished text in the form of a research paper (or similar), it seems reasonable to refer to that existing work — not only because type rules are a lot nicer to read when rendered by LaTeX instead of Markdown. Concretely, I’d like us to give some guidance wrt to this issue to proposal authors and document that at https://github.com/ghc-proposals/ghc-proposals#ghc-proposals Secondly, Simon, you seem to suggest that a large proposal like this wouldn’t be either accepted or rejected, but put into a kind a limbo state of further evaluation as seen fit. I agree that instead of outright rejection of a proposal that we consider flawed but not hopeless, we might request further elaboration and resubmission as we have done in the past. However, if a proposal passes muster, I think, we should accept it unconditionally, even if it is a large change. (If, say, at the end, the implementation is not up to scratch, then it is up to the code reviewers to reject the patches, but I don’t think, it is this committee’s job anymore.) In any case, I think, it is important make the process as clear as possible to authors, so they know what they are in for. What do you all think? Cheers, Manuel

3 7

Please review: Deprecate STM invariant, Shepherd: Manuel M T Chakravarty
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Committee, this is your secretary speaking: Deprecate STM invariant mechanism https://github.com/ghc-proposals/ghc-proposals/pull/77 was brought before the committee, by our own Ben Gamari I propose Manuel M T Chakravarty 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 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

Please review: visible dependent quantification, Shepherd: Roman Leshchinskiy
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Committee, this is your secretary speaking: Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 was brought before the committee, by our own Richard Eisenberg. 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 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

Status
by Joachim Breitner 11 Nov '17

11 Nov '17

Dear Commmittteee, Since the last status update, we * accepted the following proposals: - Type Fixity * sent the following proposals back for further refinement - NOUNPACK on function arguments * rejected the following proposals: - /none/ * were asked to review these proposals: - underscore in numeric literals * had a discussion about language extensions stability, which has been moved to a proposal of its own at https://github.com/ghc-proposals/ghc-proposals/pull/85 and has since quieted down. It is unclear if this will happen. 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 Underscores in numeric literals https://github.com/ghc-proposals/ghc-proposals/pull/76 Shepherd: Iavor Diachki Status: Iavor suggests acceptance, I sense silent agreement in the committee 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 numbers proposal
by Christopher Allen 02 Nov '17

02 Nov '17

https://github.com/ghc-proposals/ghc-proposals/pull/76#issuecomment-3399529… This appears to have near universal approval. It's certainly a feature I've been grateful for when writing Rust code. I wasn't able to find a thread about this proposal in my email archives, so I apologize if this was redundant. Could this be moved to a decision soon? Thank you, Chris Allen

3 2

Please review: underscores in numeric literals, Shepherd: Iavor Diatchki
by Joachim Breitner 02 Nov '17

02 Nov '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/76 was brought before the committee, by Takenobu Tani. I propose Iavor Diachki as the Shepherd, simply because he already responded to it. Iavor, 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