April 2017 - ghc-steering-committee

GHC steering committee participation
by Atze Dijkstra 23 Oct '17

23 Oct '17

Dear committee members, as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy(a)gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. all the best, Atze

7 11

Wrapping up Constructor Synonyms and Pattern Synonym Signatures
by Christopher Allen 28 Apr '17

28 Apr '17

Thank you to those of you that replied. I'd like to preserve the syntactic distinction that construction synonyms eliminates. Your statements have shifted me to a reject on https://github.com/ghc-proposals/ghc-proposals/pull/41 If no one has objections, I'd like to move to a reject as I think enough time has elapsed that it's unlikely to get any defenders. Speak up if you feel something was missed. Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 Summarizing peoples' replies so far: Joachim: In favor, as long as :i does the right thing. Seems under-specified, suggested the following possible relationships between signature of the pattern and the constructor: * May not differ in anything but the constraints. * Must have the same return type. * Must have the same outer type constructor in their return type. * No relation. Roman: In favor of this proposal under the "May not differ in anything but the constraints" policy and against it under any of the other three. Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that that type of the constructor should be the same as that of the pattern. Simon Marlow: I believe the statement was in favor of #42 contra #41, but I didn't get a sense of how strongly or how Simon felt about the particulars. I agree with and want to highlight Roman's point regarding, >A looser relationship between the constructor function and the pattern makes code significantly harder to read and the proposal doesn't include any justification for such a looser relationship so I would go with the strongest requirement possible. It seems to me like the respondents so far are in favor of #42, but want the strongest variant. I'd like to move to accept #42 with the "May not differ in anything but the constraints" variant. Any objections? Thank you Joachim for the status update last week. Thanks you for your time everyone, Chris Allen

6 8

Proposal #23: instance force
by Manuel M T Chakravarty 28 Apr '17

28 Apr '17

We need to decide whether we like to accept the ”instance force" proposal: https://github.com/ghc-proposals/ghc-proposals/pull/23 While I understand and am in favour of the motivation behind the proposal, I like to propose to reject the proposal in its current form. My reasons are the following: * The proposal is an ad hoc approach to adding additional type constraints to qualified types involving a specific type class. * I am against adding the proposed ”instance force” declaration form as its *main* motivation is to simplify error messages and type signatures printed by GHCi — i.e., it is of a diagnostic and informative nature. * Something like that does IMHO not belong into the language, but needs to be part of the configuration of the compilation system. In other words, it ought to be a, e.g., compiler option or a language pragma, but not a declaration form. In summary, I’d like to suggest to find an alternative means to get GHC to add the additional constraints to simplify diagnostics and type queries without encumbering the language itself. Cheers, Manuel

4 5

Please review: UNPACK on function arguments, Shepherd: Simon Marlow
by Joachim Breitner 13 Apr '17

13 Apr '17

Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/46 was brought before the committee. There was almost no discussion, and this is quite niche. I propose Simon Marlow as the Shepherd, given that he at least looked at it once, and his expertise in performance and RTS stuff. 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. FYI, the oher proposals under discussion at the moment are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept 41, reject 42. Status: Consensus is reached. Chris should summarize the verdict and assign the labels appropriately. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. instance force https://github.com/ghc-proposals/ghc-proposals/pull/23 Shepherd: Manuel Status: Awaiting shepherd recommendation. Greetings, Joachim -- 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

1 0

Please review: instance force, Shepherd: Manuel
by Joachim Breitner 13 Apr '17

13 Apr '17

Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/23 was brought before the committee. This was drafted by me, so I will hold myself back in the further discussion. I propose Manuel as the Shepherd. Yavor was more active on the PR, but he already got one assigned recently. Also, Manuel indicated that he was skeptical, so this way I cannot be accused of picking favorably. Manuel, 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. FYI, the oher proposals under discussion at the moment are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept 41, reject 42. Status: Consensus is reached. Chris should summarize the verdict and assign the labels appropriately. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. Greetings, Joachim -- 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

1 0

Status
by Joachim Breitner 03 Apr '17

03 Apr '17

[Please do not reply to this mail discussing individual proposals. Instead, reply to the appropriate thread, or start a new one.] Hi, we have now officially accepted Hex Floats https://github.com/ghc-proposals/ghc-proposals/pull/37 and rejected INCOMPLETE_CONTEXTS https://github.com/ghc-proposals/ghc-proposals/pull/34 Currently under discussion are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept both Status: expecially the first one does not seem to attract consensus. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. Also TODO (for Ben) Add @rleshchinskiy to the GitHub organization and remove @atzedijkstra https://github.com/orgs/ghc-proposals/people (or make me an owner there). Greetings, Joachim -- 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

2 1

Proposal: Accept proposal 37, Hex Float literals
by Iavor Diatchki 03 Apr '17

03 Apr '17

Hello, I was assigned to be the shepherd for the Hex Float proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/37) so I would like to propose that we accept it for implementation in GHC. This is a small change, which can be summarized as follows: - allow floating point numbers to be written using hex digits. The format is exactly the same as decimal floating point numbers, except for: - the literals start with 0x - the digits are in hex - the exponent symbol is `p` or `P`, instead of `e` or `E` - the exponent is in base 2, rather than base 10 This notation has become popular among people working with floating point numbers, as the numbers you write can be represented exactly, which is not the case for base 10 numbers. The following points were discussed: - the exact format to use, compared to what's allowed by other languages: we decided to just follow Haskell's decimal float notation, for least surprise - should overflow (which becomes `Inf`) result in a warning? We decided that this is an orthogonal issue, also relevant to decimal floating point and made a GHC ticket (#13232) - there is an odd interaction between floating point (both decimal and hex) and -XNegativeLiterals, related to negative 0, see ticket #13211 - changing the Read instances for Float and Double to recognize hex floats could break some programs, although that does not seem all that likely - there is a question of how many extra pretty printing functions to add to `Numeric`: the current thinking is that maybe just one `showHFloat` is sufficient; the alternative is to add 5, mirroring the `show[E,F,G]Float` functions for decimals. I also had a stab at implementing the basic notation here: https://phabricator.haskell.org/D3066 I haven't done the changes to the libraries yet. Please let me know if you have any objections or suggestions on what might needs to be changed. Cheers, -Iavor

7 12