Three patches for cabal

[Niklas Broberg]

>> Second there's the constructor NoMonoPatBinds, which actually
>> describes the default Haskell 98 behavior, even if GHC has a different
>> default. It's GHC's behavior that is the extension, so the constructor
>> in cabal should really be named MonoPatBinds.
>>
>> Also, the PatternSignatures constructor has been deprecated in GHC and
>> superceded by ScopedTypeVariables.
>
> Can someone please comment on these two proposed changes. I agree with
> Niklas but I'm a bit reluctant to apply the patches without at least
> some sign of agreement from someone else.
>
> Deprecating PatternSignatures seems uncontroversial, but the
> NoMonoPatBinds is potentially controversial. GHC essentially uses
> -XMonoPatBinds by default, even in H98 mode, and the user can use
> -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that
> the list of language extensions in Language.Haskell.Exceptions are
> differences from H98 so it should be MonoPatBinds to get the difference
> not NoMonoPatBinds to restore H98.
>
> In practise, since ghc uses MonoPatBinds by default it'd mean that
> people who want to get back to H98 would need to use:
>
>  ghc-options: -XNoMonoPatBinds
>
> Because the extensions field is additive, not subtractive. Using the
> name MonoPatBinds allows other compilers to implement it without it
> having to be the default.

I had a look at the source for cabal HEAD and was surprised to see
that this stuff had fallen by the wayside. What's holding it up? I
can't imagine that anyone would be against the deprecation of
PatternSignatures at least.

Cheers,

/Niklas