Three patches for cabal
niklas.broberg at gmail.com
Thu Nov 5 19:13:01 EST 2009
>> 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.
More information about the Glasgow-haskell-users