[GHC] #11298: Implicit call stack empty in instance declarations

[GHC]

#11298: Implicit call stack empty in instance declarations
-------------------------------------+-------------------------------------
        Reporter:  pikajude          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by gridaphobe):

 There are two things going on here.

 1. We intentionally changed the meaning of a bare `?loc :: CallStack` in
 8.0 to not include its own location, only function calls are appended to
 the stack now. So the first example is expected behavior in 8.0.

 2. In your second example, GHC infers a CallStack parameter for fooHelper,
 thus it's occurrence in the instance declaration is appended to the stack.
 Why does GHC infer a CallStack for the 2nd fooHelper and not the 1st?
 Because the monomorphism restriction applies in the 1st declaration and
 prevents GHC from inferring a qualified type for fooHelper.

 So both cases are expected given the current implementation, but the
 difference is a bit annoying.

 The new implementation of the CallStack solver that allows GHC to infer
 CallStack parameters is essential to fix a terrible bug in the 7.10.2
 solver, but it might make sense to prevent inferring CallStacks for top-
 level binders. I didn't do this originally since it would add another
 special case to the solver, and I don't want to do that without good
 reason. I'm not sure whether this qualifies, it's just another case of the
 monomorphism restriction. On the other hand, in this case we get different
 runtime behavior instead of an ambiguous type error, and this is
 definitely worse..

 Thanks!

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