[ghc-steering-committee] Resurrect Pattern Signatures (#119), Recommendation: accept

[Christopher Allen]

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 <marlowsd at gmail.com> 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 <cma at bitemyapp.com> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>



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