I'd be happy rejecting this. I didn't expect much support or sympathy for the ScopedTypeVariables users or for the on-going problem of extension sprawl. On Fri, May 4, 2018 at 2:42 PM, Simon Marlow wrote:

I'm slightly against this proposal. I think the reasons you gave *are* sufficient to reject it, moreover there's the additional overhead of another extension - complexity in the compiler, and cognitive overhead for programmers. Extensions aren't cheap, or at least they're not cheap enough to justify making extensions for subsets of existing extensions to cover narrow use cases like this.

Yes ScopedTypeVariables might break some code if you enable it, but I think we should all just enable it everywhere and move on. That leaves the cases where you might be working in some legacy codebase where you want to make a small change and are tempted to enable PatternSignatures because ScopedTypeVariables breaks the code somewhere else - just do without it, or enable ScopedTypeVariables and fix the breakage. I am not sympathetic to your plight :)

Cheers Simon

On 1 May 2018 at 01:13, Christopher Allen wrote:

...

This proposal splits out the faculty for assigning type signatures to variables destructured out of a pattern from ScopedTypeVariables.

https://github.com/ghc-proposals/ghc-proposals/pull/119/

My recommendation is to accept the proposal, with some reservations.

ScopedTypeVariables is one of the more popular candidates for "this should always be on regardless." The cases in which STV would be useful greatly outnumber the downsides Gundry cited in my experience. My impression of this upheld by my industrial experience and that of the other industrial programmers I've talked to in the past about ScopedTypeVariables. Almost any time it is brought up almost invariably the conversation touches on, "why isn't this on by default?"

I understand STV could break programs with overlapping names that are intended to be independent type variables, I don't presume to litigate or resolve that issue here.

Extension fatigue is wearing on the Haskell users I regularly interact with, especially as it's unclear if Haskell Prime will convene and consolidate commonly used extensions into the core language.

In my view these aren't sufficient reason to reject the proposed extension on the merits so my recommendation is to accept it as-is. I think the case for this proposal is particularly strong as it would clean up the extension's presently somewhat confusing relationship with STV.

If no objections are raised, it should be assumed that this has the assent of the committee.

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

-- Chris Allen Currently working on http://haskellbook.com

Sidebar: scoped type variables is the default in Rust as far as I know. This post demonstrates something that wouldn't work were that not the case: https://matklad.github.io/2018/05/04/encapsulating-lifetime-of-the-field.htm... They need scoped polymorphic type variables not only for ordinary type variables, but also for polymorphic lifetimes. On Fri, May 4, 2018 at 2:42 PM, Simon Marlow wrote:

I'm slightly against this proposal. I think the reasons you gave *are* sufficient to reject it, moreover there's the additional overhead of another extension - complexity in the compiler, and cognitive overhead for programmers. Extensions aren't cheap, or at least they're not cheap enough to justify making extensions for subsets of existing extensions to cover narrow use cases like this.

Yes ScopedTypeVariables might break some code if you enable it, but I think we should all just enable it everywhere and move on. That leaves the cases where you might be working in some legacy codebase where you want to make a small change and are tempted to enable PatternSignatures because ScopedTypeVariables breaks the code somewhere else - just do without it, or enable ScopedTypeVariables and fix the breakage. I am not sympathetic to your plight :)

Cheers Simon

On 1 May 2018 at 01:13, Christopher Allen wrote:

...

This proposal splits out the faculty for assigning type signatures to variables destructured out of a pattern from ScopedTypeVariables.

https://github.com/ghc-proposals/ghc-proposals/pull/119/

My recommendation is to accept the proposal, with some reservations.

ScopedTypeVariables is one of the more popular candidates for "this should always be on regardless." The cases in which STV would be useful greatly outnumber the downsides Gundry cited in my experience. My impression of this upheld by my industrial experience and that of the other industrial programmers I've talked to in the past about ScopedTypeVariables. Almost any time it is brought up almost invariably the conversation touches on, "why isn't this on by default?"

I understand STV could break programs with overlapping names that are intended to be independent type variables, I don't presume to litigate or resolve that issue here.

Extension fatigue is wearing on the Haskell users I regularly interact with, especially as it's unclear if Haskell Prime will convene and consolidate commonly used extensions into the core language.

In my view these aren't sufficient reason to reject the proposed extension on the merits so my recommendation is to accept it as-is. I think the case for this proposal is particularly strong as it would clean up the extension's presently somewhat confusing relationship with STV.

If no objections are raised, it should be assumed that this has the assent of the committee.

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

-- Chris Allen Currently working on http://haskellbook.com