From simonpj at microsoft.com Wed Mar 1 09:59:26 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Mar 2017 09:59:26 +0000 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: I’m also fine with this hex-floats thing What’s the protocol? Should committee discussion take place by default on the proposal thread itself, with exceptional out-of-band private discussion on the mailing list? Or by-default private on the mailing list? Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 28 February 2017 13:37 To: Iavor Diatchki Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals No objections from me. Looks useful and not too costly in terms of extra complexity. On 27 February 2017 at 21:34, Iavor Diatchki > wrote: 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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Mar 1 17:16:15 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 1 Mar 2017 12:16:15 -0500 Subject: [ghc-steering-committee] Please review: Eval class, Shephard: Richard In-Reply-To: References: <1488260908.32147.6.camel@joachim-breitner.de> Message-ID: <8BE700E5-9379-4C86-B39C-B2544309FD57@cs.brynmawr.edu> I agree that the proposal isn’t as specified as I’d like. Beyond that quibble, I don’t know how I could really evaluate this without knowing its true impact on existing Haskell code. If it were fully backward compatible and performant, I might be mildly in favor. But I worry it will fail on both counts... and the question is: how badly? I don’t know a way of answering that without implementing it, though! Richard > On Feb 28, 2017, at 2:02 PM, Christopher Allen wrote: > > I'm not convinced either. Generally if a silent `seq` is biting you > the problem was partiality and not insufficient lightness of the soul. > It seems like it would change sharing behavior as well, which is not > good. This affects a lot of code with unreachable branches they can't > reasonably get rid of. Often this is code that is performance > sensitive and depends on the particulars of how things are getting > shared. > > On Tue, Feb 28, 2017 at 12:38 PM, Iavor Diatchki > wrote: >> Hello, >> >> I am not very convinced about the utility of this proposal. Also, I think >> that the current specification could use more details about how the system >> should work. I wrote a comment on the pull-request thread with more >> details. >> >> -Iavor >> >> On Mon, Feb 27, 2017 at 9:48 PM, Joachim Breitner >> wrote: >>> >>> 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 at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Wed Mar 1 18:19:40 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 01 Mar 2017 10:19:40 -0800 Subject: [ghc-steering-committee] Where should we discuss? In-Reply-To: References: Message-ID: <1488392380.4493.1.camel@joachim-breitner.de> Hi, Am Mittwoch, den 01.03.2017, 09:59 +0000 schrieb Simon Peyton Jones: > What’s the protocol?  Should committee discussion take place by > default on the proposal thread itself, with exceptional out-of-band > private discussion on the mailing list?  Or by-default private on the > mailing list? I guess we have not had a serious discussion yet, so this part of the process still needs to be fleshed out. One can argue both ways. I don’t really care either way. Why don’t we just see what people prefer to do naturally for a while, and maybe only then document what we end up doing? Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu Mar 9 17:29:11 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 09 Mar 2017 18:29:11 +0100 Subject: [ghc-steering-committee] Status overview Message-ID: <1489080551.12255.4.camel@joachim-breitner.de> 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/000060.html 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 at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Thu Mar 9 17:41:59 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 09 Mar 2017 12:41:59 -0500 Subject: [ghc-steering-committee] Status overview In-Reply-To: <1489080551.12255.4.camel@joachim-breitner.de> References: <1489080551.12255.4.camel@joachim-breitner.de> Message-ID: <87k27yny8o.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi, > > as a courtesy service, here is what is currently on our plate: > Thanks Joachim! > 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/000060.html > If not, Ben, can you add Roman to the list and the github organization > (and maybe make me an owner)? > I've adeed Roman to the list and made you a maintainer of the Proposals Committee team (let me know if this isn't sufficient). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rleshchinskiy at gmail.com Thu Mar 9 20:57:31 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Thu, 9 Mar 2017 20:57:31 +0000 Subject: [ghc-steering-committee] Status overview In-Reply-To: <87k27yny8o.fsf@ben-laptop.smart-cactus.org> References: <1489080551.12255.4.camel@joachim-breitner.de> <87k27yny8o.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks, Ben! On Thu, Mar 9, 2017 at 5:41 PM, Ben Gamari wrote: > Joachim Breitner writes: > >> 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/000060.html >> If not, Ben, can you add Roman to the list and the github organization >> (and maybe make me an owner)? >> > I've adeed Roman to the list and made you a maintainer of the Proposals > Committee team (let me know if this isn't sufficient). Alas, these are the first committee-related emails I've received since Feb 4 and I'm only now finding out that I'm a member and have been assigned a proposal so I'll need a few days to get up to speed. Is there anything about procedures etc. that I should read? Thanks, Roman From mail at joachim-breitner.de Thu Mar 9 23:03:02 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Mar 2017 00:03:02 +0100 Subject: [ghc-steering-committee] Status overview In-Reply-To: <87k27yny8o.fsf@ben-laptop.smart-cactus.org> References: <1489080551.12255.4.camel@joachim-breitner.de> <87k27yny8o.fsf@ben-laptop.smart-cactus.org> Message-ID: <1489100582.1153.3.camel@joachim-breitner.de> Hi, Am Donnerstag, den 09.03.2017, 12:41 -0500 schrieb Ben Gamari: > I've adeed Roman to the list and made you a maintainer of the > Proposals > Committee team (let me know if this isn't sufficient). it is, I still cannot add Roman to https://github.com/orgs/ghc-proposals/people I guess you need to make me the owner of the organisation. Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Fri Mar 10 10:19:39 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Mar 2017 11:19:39 +0100 Subject: [ghc-steering-committee] Status overview In-Reply-To: References: <1489080551.12255.4.camel@joachim-breitner.de> <87k27yny8o.fsf@ben-laptop.smart-cactus.org> Message-ID: <1489141179.1398.1.camel@joachim-breitner.de> Hi Roman, Am Donnerstag, den 09.03.2017, 20:57 +0000 schrieb Roman Leshchinskiy: > Alas, these are the first committee-related emails I've received since > Feb 4 and I'm only now finding out that I'm a member and have been > assigned a proposal so I'll need a few days to get up to speed. Is > there anything about procedures etc. that I should read? procedures are still being defined by what they do. I guess you should read through https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and maybe have a rough look at https://mail.haskell.org/pipermail/ghc-steering-committee/ If in doubt, apply common sense or ask. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rleshchinskiy at gmail.com Sun Mar 12 15:52:03 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Sun, 12 Mar 2017 15:52:03 +0000 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal Message-ID: 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 From cma at bitemyapp.com Sun Mar 12 15:54:10 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 12 Mar 2017 10:54:10 -0500 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: Message-ID: <55948784-BA58-410B-95AF-C5636BE6ED91@bitemyapp.com> Those three reasons seem like they should be fatal by themselves. I don’t think the author was content with Simon’s condensation of the proposal but it fit my understanding. I propose we reject this as well. > On Mar 12, 2017, at 10:52 AM, Roman Leshchinskiy wrote: > > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Sun Mar 12 21:43:07 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 12 Mar 2017 17:43:07 -0400 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: <55948784-BA58-410B-95AF-C5636BE6ED91@bitemyapp.com> References: <55948784-BA58-410B-95AF-C5636BE6ED91@bitemyapp.com> Message-ID: <5A227302-B14C-4AD5-98C2-3C2E79F221F9@cs.brynmawr.edu> Agreed with rejecting this proposal. > On Mar 12, 2017, at 11:54 AM, Christopher Allen wrote: > > Those three reasons seem like they should be fatal by themselves. I don’t think the author was content with Simon’s condensation of the proposal but it fit my understanding. I propose we reject this as well. > >> On Mar 12, 2017, at 10:52 AM, Roman Leshchinskiy wrote: >> >> 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 >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From chak at justtesting.org Mon Mar 13 00:50:46 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 13 Mar 2017 11:50:46 +1100 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: Message-ID: +1 > Am 13.03.2017 um 02:52 schrieb Roman Leshchinskiy : > > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From marlowsd at gmail.com Mon Mar 13 08:40:45 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 13 Mar 2017 08:40:45 +0000 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: Message-ID: +1 from me too. Needing to add Show constraints when using trace seems like it might be a problem, but in practice (at least for me) it never has been. If it's only a debugging feature, it doesn't help with Eval, either. On 13 March 2017 at 00:50, Manuel M T Chakravarty wrote: > +1 > > > Am 13.03.2017 um 02:52 schrieb Roman Leshchinskiy < > rleshchinskiy at gmail.com>: > > > > 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 > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Mar 13 20:16:23 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 13 Mar 2017 16:16:23 -0400 Subject: [ghc-steering-committee] Eval proposal (#27) Message-ID: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> 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 Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Mar 13 21:37:17 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 13 Mar 2017 17:37:17 -0400 Subject: [ghc-steering-committee] Eval proposal (#27) In-Reply-To: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> References: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> Message-ID: <1489441037.6913.0.camel@joachim-breitner.de> Hi, Am Montag, den 13.03.2017, 16:16 -0400 schrieb Richard Eisenberg: > I move to reject this proposal. thanks for the good summary. I concur. Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Mon Mar 13 22:28:16 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 13 Mar 2017 22:28:16 +0000 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: Message-ID: I agree with rejection. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Roman Leshchinskiy | Sent: 12 March 2017 15:52 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS | pragma proposal | | 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From marlowsd at gmail.com Tue Mar 14 10:04:42 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 14 Mar 2017 10:04:42 +0000 Subject: [ghc-steering-committee] Eval proposal (#27) In-Reply-To: <1489441037.6913.0.camel@joachim-breitner.de> References: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> <1489441037.6913.0.camel@joachim-breitner.de> Message-ID: Agreed. On 13 March 2017 at 21:37, Joachim Breitner wrote: > Hi, > > Am Montag, den 13.03.2017, 16:16 -0400 schrieb Richard Eisenberg: > > I move to reject this proposal. > > thanks for the good summary. I concur. > > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleshchinskiy at gmail.com Wed Mar 15 06:50:50 2017 From: rleshchinskiy at gmail.com (Roman Leschinskiy) Date: Wed, 15 Mar 2017 06:50:50 +0000 Subject: [ghc-steering-committee] Eval proposal (#27) In-Reply-To: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> References: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> Message-ID: > On 13 Mar 2017, at 20:16, Richard Eisenberg wrote: > > I move to reject this proposal. I agree. Roman From simonpj at microsoft.com Wed Mar 15 23:04:32 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 15 Mar 2017 23:04:32 +0000 Subject: [ghc-steering-committee] Eval proposal (#27) In-Reply-To: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> References: <5383D4E2-D039-4EC4-A053-812EF0EA718C@cs.brynmawr.edu> Message-ID: I agree. You might need to write up the notes below into a publicly-readable form, but that should not be hard. (In general, for all our “verdicts” I think we should write up a rationale for the author and others to read.) Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 13 March 2017 20:16 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Eval proposal (#27) 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 Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Mar 20 23:24:06 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Mar 2017 19:24:06 -0400 Subject: [ghc-steering-committee] Please review: Constructor Synonyms / pattern synonym constructor signatures, Shephard: Chris Allen Message-ID: <1490052246.10470.2.camel@joachim-breitner.de> 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 at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Mar 20 23:26:05 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Mar 2017 19:26:05 -0400 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: Message-ID: <1490052365.10470.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 12.03.2017, 15:52 +0000 schrieb Roman Leshchinskiy: > I propose we reject this. there seems to be consensus on this. If nobody shouts out real soon now, I will official mark this as approved tomorrow or so. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Mar 20 23:26:44 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Mar 2017 19:26:44 -0400 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: <1490052404.10470.4.camel@joachim-breitner.de> Am Montag, den 27.02.2017, 13:34 -0800 schrieb Iavor Diatchki: > > 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. there seems to be consensus on this. If nobody shouts out real soon now, I will official mark this as approved tomorrow or so. Greetings, Joachim -- -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Tue Mar 21 00:55:34 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 20 Mar 2017 20:55:34 -0400 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: <1490052404.10470.4.camel@joachim-breitner.de> References: <1490052404.10470.4.camel@joachim-breitner.de> Message-ID: <87k27jih2x.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Am Montag, den 27.02.2017, 13:34 -0800 schrieb Iavor Diatchki: > >> >> 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. > > there seems to be consensus on this. If nobody shouts out real soon > now, I will official mark this as approved tomorrow or so. > Sounds good to me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From cma at bitemyapp.com Tue Mar 21 01:37:07 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Mar 2017 20:37:07 -0500 Subject: [ghc-steering-committee] Please review: Constructor Synonyms / pattern synonym constructor signatures, Shephard: Chris Allen In-Reply-To: <1490052246.10470.2.camel@joachim-breitner.de> References: <1490052246.10470.2.camel@joachim-breitner.de> Message-ID: Works for me, thank you for the process outline. I'll offer my thoughts on the Eval class proposal after I get a reply from Simon. I’m writing up signatures for pattern synonym constructors now. > On Mar 20, 2017, at 6:24 PM, Joachim Breitner wrote: > > 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org From chak at justtesting.org Tue Mar 21 01:37:01 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 21 Mar 2017 12:37:01 +1100 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: <1490052365.10470.3.camel@joachim-breitner.de> References: <1490052365.10470.3.camel@joachim-breitner.de> Message-ID: <3D354E2E-1879-4502-A141-6EB655B11869@justtesting.org> Approved? I assume, you mean rejected. (You approve the rejection ;) > Am 21.03.2017 um 10:26 schrieb Joachim Breitner : > > Hi, > > Am Sonntag, den 12.03.2017, 15:52 +0000 schrieb Roman Leshchinskiy: >> I propose we reject this. > > there seems to be consensus on this. If nobody shouts out real soon > now, I will official mark this as approved tomorrow or so. > > Greetings, > Joachim > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org_______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From cma at bitemyapp.com Tue Mar 21 01:58:46 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Mar 2017 20:58:46 -0500 Subject: [ghc-steering-committee] Please review: Constructor Synonyms / pattern synonym constructor signatures, Shephard: Chris Allen In-Reply-To: <1490052246.10470.2.camel@joachim-breitner.de> References: <1490052246.10470.2.camel@joachim-breitner.de> Message-ID: I just saw this comment, https://github.com/ghc-proposals/ghc-proposals/pull/41#issuecomment-287924726 Did you mean to assign me both Eval class and pattern synonym constructors? I’m trying to formulate an evaluation of #42 in isolation from #41 but I don’t think this is what you intended and rather that I should be discussing 41 and 42, not 42 and Eval class. > On Mar 20, 2017, at 6:24 PM, Joachim Breitner wrote: > > 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Mar 21 03:16:13 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Mar 2017 23:16:13 -0400 Subject: [ghc-steering-committee] Please review: Constructor Synonyms / pattern synonym constructor signatures, Shepherd: Chris Allen In-Reply-To: References: <1490052246.10470.2.camel@joachim-breitner.de> Message-ID: <1490066173.10470.5.camel@joachim-breitner.de> Hi, sorry, copy’n’paste error. Please shepherd #41 and #42 (and not #27). Greetings, Joachim Am Montag, den 20.03.2017, 20:58 -0500 schrieb Christopher Allen: > I just saw this comment, https://github.com/ghc-proposals/ghc-proposa > ls/pull/41#issuecomment-287924726 > > Did you mean to assign me both Eval class and pattern synonym > constructors? I’m trying to formulate an evaluation of #42 in > isolation from #41 but I don’t think this is what you intended and > rather that I should be discussing 41 and 42, not 42 and Eval class. > > > > On Mar 20, 2017, at 6:24 PM, Joachim Breitner > r.de> wrote: > > > > 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 at joachim-breitner.de • https://www.joachim-breitner.de/ > >   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > >   Debian Developer: nomeata at debian.org > > -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Tue Mar 21 03:16:47 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Mar 2017 22:16:47 -0500 Subject: [ghc-steering-committee] Please review: Constructor Synonyms / pattern synonym constructor signatures, Shepherd: Chris Allen In-Reply-To: <1490066173.10470.5.camel@joachim-breitner.de> References: <1490052246.10470.2.camel@joachim-breitner.de> <1490066173.10470.5.camel@joachim-breitner.de> Message-ID: Right-o. Thank you. > On Mar 20, 2017, at 10:16 PM, Joachim Breitner wrote: > > Hi, > > sorry, copy’n’paste error. Please shepherd #41 and #42 (and not #27). > > Greetings, > Joachim > > Am Montag, den 20.03.2017, 20:58 -0500 schrieb Christopher Allen: >> I just saw this comment, https://github.com/ghc-proposals/ghc-proposa >> ls/pull/41#issuecomment-287924726 >> >> Did you mean to assign me both Eval class and pattern synonym >> constructors? I’m trying to formulate an evaluation of #42 in >> isolation from #41 but I don’t think this is what you intended and >> rather that I should be discussing 41 and 42, not 42 and Eval class. >> >> >>> On Mar 20, 2017, at 6:24 PM, Joachim Breitner >> r.de> wrote: >>> >>> 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 at joachim-breitner.de • https://www.joachim-breitner.de/ >>> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >>> Debian Developer: nomeata at debian.org >> >> > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org From mail at joachim-breitner.de Tue Mar 21 03:17:58 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Mar 2017 23:17:58 -0400 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: <3D354E2E-1879-4502-A141-6EB655B11869@justtesting.org> References: <1490052365.10470.3.camel@joachim-breitner.de> <3D354E2E-1879-4502-A141-6EB655B11869@justtesting.org> Message-ID: <1490066278.10470.7.camel@joachim-breitner.de> Hi, I approve your correction. Actually, to set good procedural precedence, I would suggest that the Shepherd (in this case Roman) marks the proposal as accepted or rejected on Github, and includes a rationale (esp. for a rejection). Greetings, Joachim Am Dienstag, den 21.03.2017, 12:37 +1100 schrieb Manuel M T Chakravarty: > Approved? I assume, you mean rejected. (You approve the rejection ;) > > > Am 21.03.2017 um 10:26 schrieb Joachim Breitner > ner.de>: > > > > Hi, > > > > Am Sonntag, den 12.03.2017, 15:52 +0000 schrieb Roman Leshchinskiy: > > > I propose we reject this. > > > > there seems to be consensus on this. If nobody shouts out real soon > > now, I will official mark this as approved tomorrow or so. > > > > Greetings, > > Joachim > > --  > > Joachim “nomeata” Breitner > >   mail at joachim-breitner.de • https://www.joachim-breitner.de/ > >   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > >   Debian Developer: nomeata at debian.org_____________________________ > > __________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm > > ittee > > -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Tue Mar 21 05:55:28 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 21 Mar 2017 00:55:28 -0500 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors Message-ID: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> 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/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000-constructor-synonyms.rst - https://github.com/treeowl/ghc-proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000-bidir-constr-sigs.rst 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 From mail at joachim-breitner.de Tue Mar 21 13:43:04 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 21 Mar 2017 09:43:04 -0400 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors In-Reply-To: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> References: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> Message-ID: <1490103784.26046.3.camel@joachim-breitner.de> Hi, Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen: > 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 it is worth pointing out that under this proposal, constructor FireMissles :: IO () constructor FireMissles = fireMissles (without a pattern) is also valid. In other words: The capitalization of an identifier will no longer be of significance. This makes me dislike the proposal. I guess I would be fine with it if "constructor" were only ever used together with "pattern". In that case, it would be simply a different syntax for the other proposal. > Proposal #42 would add type signatures for bidirectional pattern > synonym constructor functions. > > 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. In principle in favor of this. I am less concerned about what :i would show. It could simply use comments like in the following to explain directionality and possibly different signatures. :i Just -- real constructor Just :: a -> Maybe a :i HashOf -- unidirectional Hash :: Hashable a => Hash -> a -- pattern matching only :i Snoc -- bidirectional, same types Snoc :: [a] -> a -> [a] :i Zero -- bidirectional, diffrent types, as above Zero :: (Eq a, Num a) => a -- when matching Zero :: Num a => a -- when constructing The proposal does not address if the signatures of the constructor and the signature of the pattern have to be in any way related. Possible design choices are: * 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. This ought to be clarified. Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rleshchinskiy at gmail.com Tue Mar 21 22:57:28 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Tue, 21 Mar 2017 22:57:28 +0000 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: <1490066278.10470.7.camel@joachim-breitner.de> References: <1490052365.10470.3.camel@joachim-breitner.de> <3D354E2E-1879-4502-A141-6EB655B11869@justtesting.org> <1490066278.10470.7.camel@joachim-breitner.de> Message-ID: Hi, On Tue, Mar 21, 2017 at 3:17 AM, Joachim Breitner wrote: > > Actually, to set good procedural precedence, I would suggest that the > Shepherd (in this case Roman) marks the proposal as accepted or > rejected on Github, and includes a rationale (esp. for a rejection). I'd love to do so but I don't seem to have write access. Thanks, Roman From rleshchinskiy at gmail.com Tue Mar 21 23:26:37 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Tue, 21 Mar 2017 23:26:37 +0000 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors In-Reply-To: <1490103784.26046.3.camel@joachim-breitner.de> References: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> <1490103784.26046.3.camel@joachim-breitner.de> Message-ID: Hi, I'm in a slightly difficult situation here since I quite dislike the current pattern synonyms extension. I'll try nonetheless. On Tue, Mar 21, 2017 at 1:43 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen: >> Proposal #41 is constructor synonyms. This would allow users to >> [...] > > it is worth pointing out that under this proposal, > > constructor FireMissles :: IO () > constructor FireMissles = fireMissles > > (without a pattern) is also valid. In other words: The capitalization > of an identifier will no longer be of significance. > > This makes me dislike the proposal. I completely agree. In fact, this proposal is basically about allowing value variable names to start with an upper case letter so if we want to go that way then I'm not sure why the keyword 'constructor' is necessary at all. I would much prefer not to go that way, though, so I'm against #41. >> Proposal #42 would add type signatures for bidirectional pattern >> synonym constructor functions. >> [...] This seems sensible provided there is a strong relation between the types of the constructor and the pattern. > The proposal does not address if the signatures of the constructor and > the signature of the pattern have to be in any way related. Possible > design choices are: > * 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. > This ought to be clarified. This is a very good point. I'd be in favour of this proposal under the "May not differ in anything but the constraints" policy and against it under any of the other three. 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. Thanks, Roman From ben at well-typed.com Wed Mar 22 01:07:34 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Mar 2017 21:07:34 -0400 Subject: [ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal In-Reply-To: References: <1490052365.10470.3.camel@joachim-breitner.de> <3D354E2E-1879-4502-A141-6EB655B11869@justtesting.org> <1490066278.10470.7.camel@joachim-breitner.de> Message-ID: <874lymi0fd.fsf@ben-laptop.smart-cactus.org> Roman Leshchinskiy writes: > Hi, > > On Tue, Mar 21, 2017 at 3:17 AM, Joachim Breitner > wrote: >> >> Actually, to set good procedural precedence, I would suggest that the >> Shepherd (in this case Roman) marks the proposal as accepted or >> rejected on Github, and includes a rationale (esp. for a rejection). > > I'd love to do so but I don't seem to have write access. Roman, Can you remind me of your GitHub username? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Wed Mar 22 10:13:00 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 22 Mar 2017 10:13:00 +0000 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors In-Reply-To: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> References: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> Message-ID: Some thoughts · To me it's clear that we should abandon #41 in favour of #42. Indeed the author did so himself, but then re-opened it saying only "@kosmikus thinks this should be reopened". I could elaborate, but see the discussion on #41. I think it’s pretty much a consensus. · For #42, I’m mildly in favour, as I said on the thread. (But no holes please!) · I agree with Roman that that type of the constructor should be the same as that of the pattern, constrains aside. We can always loosen later if there is well-supported evidence that doing so would be good. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Christopher Allen | Sent: 21 March 2017 05:55 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Constructor synonyms, signatures on | pattern synonym constructors | | 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/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000 | -constructor-synonyms.rst | - https://github.com/treeowl/ghc- | proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000 | -bidir-constr-sigs.rst | | 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 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Mar 23 10:00:54 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 23 Mar 2017 10:00:54 +0000 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors In-Reply-To: References: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> <1490103784.26046.3.camel@joachim-breitner.de> Message-ID: On 21 March 2017 at 23:26, Roman Leshchinskiy wrote: > Hi, > > I'm in a slightly difficult situation here since I quite dislike the > current pattern synonyms extension. I'll try nonetheless. > > On Tue, Mar 21, 2017 at 1:43 PM, Joachim Breitner > wrote: > > Hi, > > > > Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen: > >> Proposal #41 is constructor synonyms. This would allow users to > >> [...] > > > > it is worth pointing out that under this proposal, > > > > constructor FireMissles :: IO () > > constructor FireMissles = fireMissles > > > > (without a pattern) is also valid. In other words: The capitalization > > of an identifier will no longer be of significance. > > > > This makes me dislike the proposal. > > I completely agree. In fact, this proposal is basically about allowing > value variable names to start with an upper case letter so if we want > to go that way then I'm not sure why the keyword 'constructor' is > necessary at all. I would much prefer not to go that way, though, so > I'm against #41. > Yes, I think I agree with this too. The point of pattern synonyms is to let you define something that to the importer of a module looks exactly like a data constructor, while allowing the author of the module to change its implementation. It fills in a missing opportunity for abstraction in the language. But constructor synonyms go much further than this, allowing you to define something that looks like a data constructor but doesn't behave anything like one. It drops the requirement that the constructor be expressible as a pattern. If you want to do this, define a function! Why not solve the original problem by allowing a separate type signature on the constructor in the pattern synonym? There's already an example of this in the proposal: pattern Zero :: (Eq a, Num a) => a pattern Zero <- ((== 0) -> True) where Zero :: Num a => a Zero = 0 (the proposal has the signature on Zero slightly wrong, I think). This seems like it would address the problem but without also overly generalising what a conid can represent, and avoids the issues with import/export. Digressing a bit, I wish it were possible to write the pattern above as pattern Zero :: (Eq a, Num a) => a pattern Zero <- x | x == 0 where Zero :: Num a => a Zero = 0 because I think ViewPatterns were a mistake. But that's a proposal for another day :) Cheers Simon >> Proposal #42 would add type signatures for bidirectional pattern > >> synonym constructor functions. > >> [...] > > This seems sensible provided there is a strong relation between the > types of the constructor and the pattern. > > > The proposal does not address if the signatures of the constructor and > > the signature of the pattern have to be in any way related. Possible > > design choices are: > > * 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. > > This ought to be clarified. > > This is a very good point. I'd be in favour of this proposal under the > "May not differ in anything but the constraints" policy and against it > under any of the other three. 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. > > Thanks, > > Roman > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Mar 23 14:42:44 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 23 Mar 2017 14:42:44 +0000 Subject: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors In-Reply-To: References: <39832449-8E8A-4464-8F25-5F9858AB0D02@bitemyapp.com> <1490103784.26046.3.camel@joachim-breitner.de> Message-ID: Digressing a bit, I wish it were possible to write the pattern above as I agree! See: https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative Maybe we should work that up into a new GHC proposal. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 23 March 2017 10:01 To: Roman Leshchinskiy Cc: ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors On 21 March 2017 at 23:26, Roman Leshchinskiy > wrote: Hi, I'm in a slightly difficult situation here since I quite dislike the current pattern synonyms extension. I'll try nonetheless. On Tue, Mar 21, 2017 at 1:43 PM, Joachim Breitner > wrote: > Hi, > > Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen: >> Proposal #41 is constructor synonyms. This would allow users to >> [...] > > it is worth pointing out that under this proposal, > > constructor FireMissles :: IO () > constructor FireMissles = fireMissles > > (without a pattern) is also valid. In other words: The capitalization > of an identifier will no longer be of significance. > > This makes me dislike the proposal. I completely agree. In fact, this proposal is basically about allowing value variable names to start with an upper case letter so if we want to go that way then I'm not sure why the keyword 'constructor' is necessary at all. I would much prefer not to go that way, though, so I'm against #41. Yes, I think I agree with this too. The point of pattern synonyms is to let you define something that to the importer of a module looks exactly like a data constructor, while allowing the author of the module to change its implementation. It fills in a missing opportunity for abstraction in the language. But constructor synonyms go much further than this, allowing you to define something that looks like a data constructor but doesn't behave anything like one. It drops the requirement that the constructor be expressible as a pattern. If you want to do this, define a function! Why not solve the original problem by allowing a separate type signature on the constructor in the pattern synonym? There's already an example of this in the proposal: pattern Zero :: (Eq a, Num a) => a pattern Zero <- ((== 0) -> True) where Zero :: Num a => a Zero = 0 (the proposal has the signature on Zero slightly wrong, I think). This seems like it would address the problem but without also overly generalising what a conid can represent, and avoids the issues with import/export. Digressing a bit, I wish it were possible to write the pattern above as pattern Zero :: (Eq a, Num a) => a pattern Zero <- x | x == 0 where Zero :: Num a => a Zero = 0 because I think ViewPatterns were a mistake. But that's a proposal for another day :) Cheers Simon >> Proposal #42 would add type signatures for bidirectional pattern >> synonym constructor functions. >> [...] This seems sensible provided there is a strong relation between the types of the constructor and the pattern. > The proposal does not address if the signatures of the constructor and > the signature of the pattern have to be in any way related. Possible > design choices are: > * 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. > This ought to be clarified. This is a very good point. I'd be in favour of this proposal under the "May not differ in anything but the constraints" policy and against it under any of the other three. 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. Thanks, Roman _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Mar 27 15:18:41 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Mar 2017 11:18:41 -0400 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: <1490052404.10470.4.camel@joachim-breitner.de> References: <1490052404.10470.4.camel@joachim-breitner.de> Message-ID: <1490627921.1781.2.camel@joachim-breitner.de> Hi, Am Montag, den 20.03.2017, 19:26 -0400 schrieb Joachim Breitner: > Am Montag, den 27.02.2017, 13:34 -0800 schrieb Iavor Diatchki: > > 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. > > there seems to be consensus on this. If nobody shouts out real soon > now, I will official mark this as approved tomorrow or so. I think it would set better procedural precedent if the shepherd does that. Iavor, can you mark the proposal as accepted (with a small rationale) and close the PR? Thanks, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: