- ghc-steering-committee

Proposal #46: NOUNPACK pragmas for function arguments
by Simon Marlow 08 May '17

08 May '17

https://github.com/ghc-proposals/ghc-proposals/pull/46 I tentatively propose that we accept this proposal. Briefly, the proposal is to allow a NOUNPACK pragma in a *type signature* to indicate that a value should not be unpacked by the worker-wrapper transformation, e.g.: insertR :: Ord k => {-# NOUNPACK #-} k -> v -> Map k v -> Map k v insertR k v m = go k k v m where go :: Ord k => {-# NOUNPACK #-} k -> k -> v -> Map k v -> Map k v go kp k v m = ... The idea is that sometimes unpacking a strict argument leads to worse code because the repacking doesn't get simplified away, and it's hard for worker-wrapper to tell that up front. It's quite difficult for the programmer to avoid this problem currently - the one trick we have available is the `lazy` pseudo-function, but that's difficult to use for this purpose because you have to ensure that *all* uses of the argument are made lazy, and there can be collateral damage. It's the wrong tool to solve this problem, but it's the only tool we have. I've had this issue personally, and I've worked around it with `lazy`, but it's an ugly and brittle workaround, and something better is needed. If we assume that NOUNPACK can only occur on the left of an arrow (rather like UNPACK/NOUNPACK in a GADT signature), then it's a fairly straightforward extension, and just requires plumbing the information through to the demand analyser / worker-wrapper. The dual UNPACK annotation also makes sense, I think, although it's not part of this proposal. I can imagine it being a future extension. Drawbacks I see: - It doesn't let you say anything more detailed than just "no", e.g. you can't say "don't unpack the first field of the record" - It requires a type signature, which you wouldn't otherwise need. I suppose you could use PartialTypeSignatures. - It doesn't let you say anything about strictness, only unpacking. If a NOUNPACK argument is inferred by the demand analyser to be strict, callers can use call-by-value. Overall I don't see any fatal flaws and there are benefits. It's not a beautiful extension by any means, but I don't think it's expensive or complicated to implement. I suggest we accept it. Thoughts? Cheers Simon

2 1

Status
by Joachim Breitner 06 May '17

06 May '17

[Please do not reply to this mail discussing individual proposals. Instead, reply to the appropriate thread, or start a new one.] Hi, currently under discussion are: 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. We are waiting for Richard to make a new decision suggestion. Force Instance https://github.com/ghc-proposals/ghc-proposals/pull/23 Shepherd: Manuel Status: Manuel suggests rejection, which is generally agreed by the committee. Manuel, I believe you can go ahead and reject the proposal, ideally with a short rationale. UNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: Awaiting a recommendation from Simon Also still 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 Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

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 12 Apr '17

12 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 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 21 Mar '17

21 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