[ghc-steering-committee] Proposal 34: The INCOMPLETE_CONTEXTS pragma proposal

Richard Eisenberg rae at cs.brynmawr.edu
Sun Mar 12 21:43:07 UTC 2017


Agreed with rejecting this proposal.

> On Mar 12, 2017, at 11:54 AM, Christopher Allen <cma at bitemyapp.com> 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 <rleshchinskiy at gmail.com> 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



More information about the ghc-steering-committee mailing list