- ghc-steering-committee

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

Constructor synonyms, signatures on pattern synonym constructors
by Christopher Allen 23 Mar '17

23 Mar '17

I’m shepherding this two intertwined proposals, the Github discussions are located at: - https://github.com/ghc-proposals/ghc-proposals/pull/41 - https://github.com/ghc-proposals/ghc-proposals/pull/42 The rendered proposals are located at time of review at: - https://github.com/treeowl/ghc-proposals/blob/680d909a07b10b6a37a64adf174ee… - https://github.com/treeowl/ghc-proposals/blob/559df2865db8e4427b1f24d3100e5… Very briefly, Proposal #41 is constructor synonyms. This would allow users to define variables with capitalized names and operators that begin with colons. They are meant to complement pattern synonyms. This example from the rendered proposal captures the idea and complementarity well I think: pattern NF :: a -> NF a pattern NF a <- UnsafeNF a constructor NF :: NFData a => a -> NF a constructor NF a = a `deepseq` UnsafeNF a pattern Zero :: (Eq a, Num a) => a pattern Zero <- ((== 0) -> True) constructor Zero :: Num a => a constructor Zero = 0 Proposal #42 would add type signatures for bidirectional pattern synonym constructor functions. Currently we can write this: pattern Zero :: (Num a, Eq a) => a pattern Zero <- ((== 0) -> True) where Zero = 0 Per Feuer: >The trouble in this case is that the Eq constraint from the pattern "infects" the constructor. So if I have a number type I can't test for equality, I can't use Zero to construct it. It would permit writing things like this instead: pattern Zero :: (Eq a, Num a) => a pattern Zero <- ((== 0) -> True) where Zero :: Num a => a -- optional Zero = 0 This would prevent the pattern’s Eq constraint from “infecting” using Zero as a constructor, which doesn’t actually need Eq. — My thoughts follow — I think Richard’s right about how we’ll need to handle compatibility. I agree that the current warnings policy is a bit restrictive but it’s not worth getting people riled up over it. I agree with Simon's comment on #42. I think we need to take seriously whether or not this proposal compromises the use-case of the naïve user consuming a library API that uses pattern constructors. Partly why I feel this is important is that as much debate as it draws, Haskell users consuming a lens-based API are able to cargo cult and move on with what they’re doing. I think pattern constructors should be held to a higher usability standard than lens due to looking like data constructors and being baked into the implementation. This seems to clear up a limitation in expressiveness with few downsides as long as we avoid using holes and respect the community’s desires on backwards compatibility. Avoiding holes should make implementation easier and have fewer unpredictable behaviors down the road as well. — My recommendation for the proposal — My recommendation is that we accept both proposals. My reservation would be that it shouldn't have serious downsides for the existing users of pattern synonyms, be they authors or consumers. Cheers, Chris

5 5

Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal
by Roman Leshchinskiy 22 Mar '17

22 Mar '17

Hi, I propose we reject this. Reasons: 1. The motivation is quite weak. In the case of tracing this seems like a rather large hammer for such a small nail. The other examples in the document aren't convincing to me at all. As Simon PJ points out, a wildcard context would handle most of the cases in question. 2. The extension is dangerous, as the proposal itself acknowledges. It explicitly requires that "Hackage should refuse to accept any package upload" with this pragma. To me, this seems like far too much machinery for this (and a lot of people don't use Hackage). A compiler flag might be more reasonable but even then, I don't see the benefits as being worth it. 3. The extension is underspecified. It's not clear to me what the exact semantics are and what an implementation would look like. Thanks, Roman

8 10

Please review: Constructor Synonyms / pattern synonym constructor signatures, Shephard: Chris Allen
by Joachim Breitner 21 Mar '17

21 Mar '17

Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/27 and https://github.com/ghc-proposals/ghc-proposals/pull/42 was brought before the committee. The proposals are related, so it makes sense to decide on them at once. I propose Chris as the Shepherd. (But this was a relatively arbitrary decision, and Chris, if you are unhappy with this, I can arbitrary appoint someone else.) Chris, 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: Hex Floats Shephard: Iavor https://github.com/ghc-proposals/ghc-proposals/pull/37 Current tendency of the committee: In favor. INCOMPLETE_CONTEXTS Shephard: Roman https://github.com/ghc-proposals/ghc-proposals/pull/34 Current tendency of the committee: Against. 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 4

Eval proposal (#27)
by Richard Eisenberg 16 Mar '17

16 Mar '17

I am shepherding the Eval class proposal, #29. Very, very briefly, this proposes to bring back > class Eval a where > seq :: a -> b -> b The author of the proposal cites some motivation, but a recurring theme in the discussion is that this is just the first step toward some ill-defined promised land. The author himself admits he’s not quite sure what the promised land holds, other than safety under eta-expansion, along with a restoration of parametricity. The proposal includes a new extension, on by default, -XUniversalEval, that adds Eval constraints in many places. Even with -XUniversalEval, however, this extension is not fully backward compatible, in corner cases (seq’ing in a class method; polymorphic recursion, possibly higher-rank types. I move to reject this proposal. The author (along with a few others) argues that this brings some nice theoretical properties to Haskell. I agree here. But the cost doesn’t seem to be worth the benefit, especially considering that this may be the first step toward some ill-specified goal. In short, while I might be happy enough with the language proposed here, I don’t relish the idea of getting from where we are to that language, and I don’t think the gain is worth the pain. You can see the PR here: https://github.com/ghc-proposals/ghc-proposals/pull/27 <https://github.com/ghc-proposals/ghc-proposals/pull/27> Richard

5 4

Status overview
by Joachim Breitner 10 Mar '17

10 Mar '17

Hi, as a courtesy service, here is what is currently on our plate: Hex Floats Shephard: Iavor https://github.com/ghc-proposals/ghc-proposals/pull/37 Current tendency of the committee: In favor. INCOMPLETE_CONTEXTS Shephard: Roman https://github.com/ghc-proposals/ghc-proposals/pull/34 Roman has not started to propose an action here. Roman, were you on the list when I sent https://mail.haskell.org/pipermail/ghc-steering-committee/2017-February/000… If not, Ben, can you add Roman to the list and the github organization (and maybe make me an owner)? The Eval class proposal (Shephard: Richard) was sent back to the author for further revision. 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

3 4

Please review: Eval class, Shephard: Richard
by Joachim Breitner 01 Mar '17

01 Mar '17

Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/27 was brought before the committee. I propose Richard as the Shepherd. Richard, 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/

4 3