>> 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 _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
