March 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

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

02 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 15 Mar '17

15 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