[GHC] #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition

[GHC]

#15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top
level definition
-------------------------------------+-------------------------------------
        Reporter:  theindigamer      |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  low               |            Milestone:  ⊥
       Component:  Compiler          |              Version:  8.6.2
      Resolution:                    |             Keywords:
                                     |  MonoLocalBinds,
                                     |  MonomorphismRestriction
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect         |  Unknown/Multiple
  error/warning at compile-time      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by theindigamer):

 ==== Proposal 1 (somewhat radical)

 In my experience, such error messages (the ones which are inaccurate, in
 contrast to most other messages) very often involve the
 MonomorphismRestriction in one way or another, as well as some function in
 the middle not having an explicit signature. Often the problem will go
 away once you add that missing signature.

 So, if you get an error with MonomorphismRestriction on, and the error
 involves functions which do not have explicit signatures ("involves" would
 need to be more precisely defined...) - try turning it off and see if the
 error goes away. If it does, inform the user the "hey,
 MonomorphismRestriction is causing a problem, so please annotate foo with
 the type X" that I inferred with NoMonomorphismRestriction.

 I don't know how practical this is or whether it could lead to undesirable
 consequences.

 ==== Proposal 2

 In this particular case at least, a better error message would be with the
 substituted types -

 {{{
 Inferred picker :: [Char] -> [Char] -> [Char] due to

 7 |     picker "x" "y"

 and also picker :: Num a => a -> a -> a due to

 8 |     picker 10 11

 which conflict. Looks like picker doesn't have an explicit type
 signature - try providing one to fix the issue, or get a more informative
 error message.
 }}}

 Of course, the exact wording itself is not important, but now it is much
 clearer what the source of the problem is.

 I'm not sure what the appropriate level of generality is here (to give
 this kind of error message).

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15931#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler