Top-level bindings are broken for polymorphic values

Thanks for the report. Your first example is deliberately broken (relative to Haskell98); see http://www.haskell.org/ghc/docs/latest/html/users_guide/monomorphism.html for details, or use -XNoMonoPatBinds to get the Haskell98-specified behaviour.

If you give a type signature for x then I would have expected it to work; Simon?

yallop, I assume you ran into this problem in a real program?

Thanks for the reply. Yes, I ran into the problem in a real program.

I have code that looks like this:

   (x1,...,xn) = (e1,...en)
      where y = e
            z = f

which is generated via Template Haskell. Sometimes the bindings are supposed to be polymorphic, sometimes not.

It looks like I have two choices, neither of which is particularly desirable:

1. Change the generation scheme to emit less elegant code, which will also complicate the generation code.
2. Require all users of the library to add -XNoMonoPatBinds

From a user's perspective (at least, from this user's), defaulting to monomorphic pattern bindings looks like quite an unfortunate choice:

1. It doesn't bring any actual benefits to the user (that I can see).
2. It breaks compatibility with Haskell 98, so code that works on other implementations mysteriously fails without so much as a warning.
3. It generates quite unusable code: there's no realistic use for functions of type

           GHC.Prim.Any -> GHC.Prim.Any
   

   so why default to generating that sort of thing?
4. It makes it more difficult to transform programs, since you can no longer replace

          x = f (a,b)
   

   with

          (c,d) = (a,b)
          f (c,d)
   

It's difficult to see how it can simplify the implementation, since you still have to cope with -XNoMonoPatBinds. There must be *some* reason for this change, but what can it be?

Linking to the Haskell' page with the motivation for this change: http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/MonomorphicPatternBindings

As for whether it makes the implementation simpler, I presume the intention was to deprecate and eventually remove -XNoMonoPatBinds at which point the complexities to deal with polymorphic pattern bindings would go away. (however we can't do that while we still want to support Haskell 98, of course). I'm going to follow up on this with the Haskell' committee.

*more* ugly warts? I thought we were trying to get *rid* of those ...

Any bets on which 6.10.x release will revert this?

So GHC is behaving "correctly" here, although for Haskell' we've decided to do things differently; see #2357. Hopefully we'll be able to implement the change for 6.10.1.