Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

newer
Constructor synonyms, signatures...

Roman Leshchinskiy

12 Mar 2017 12 Mar '17

3:52 p.m.

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

Show replies by date

Christopher Allen

12 Mar 12 Mar

3:54 p.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

9:43 p.m.

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Manuel M T Chakravarty

13 Mar 13 Mar

12:50 a.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

8:40 a.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

+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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

10:28 p.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

I agree with rejection. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Roman Leshchinskiy | Sent: 12 March 2017 15:52 | To: ghc-steering-committee@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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

20 Mar 20 Mar

11:26 p.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

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@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Manuel M T Chakravarty

21 Mar 21 Mar

1:37 a.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

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@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

3:17 a.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

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 :

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@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org_____________________________ __________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm ittee

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Roman Leshchinskiy

10:57 p.m.

New subject: Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

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

Ben Gamari

22 Mar 22 Mar

1:07 a.m.

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

3036

Age (days ago)

3046

Last active (days ago)

List overview

Download

10 comments

8 participants

participants (8)

Ben Gamari
Christopher Allen
Joachim Breitner
Manuel M T Chakravarty
Richard Eisenberg
Roman Leshchinskiy
Simon Marlow
Simon Peyton Jones