[GHC] #15928: Reduction stack overflow when using "coerce"

[GHC]

#15928: Reduction stack overflow when using "coerce"
-------------------------------------+-------------------------------------
        Reporter:  harendra          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.3
       Component:  Compiler          |              Version:  8.6.2
      Resolution:                    |             Keywords:
Operating System:  MacOS X           |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Replying to [comment:2 harendra]:
 > I think GHC needs to move on from "by GHC developers for GHC developers"
 to "by GHC developers for mortal Haskell programmers". ...

 I agree that we do a poor job of this. I think this needs to be more of a
 priority for us, which is why I recommended time spent on error messages
 in the recent survey put out about what to spend 6 months of developer
 time on.

 I think the only answer is to have interactive error messages, where an
 IDE and GHC work together to allow, e.g., a user to right-click on a term
 in an error message and get a definition, or can right-click on a
 constraint and get information about how GHC thought that the constraint
 should be solved. #8809 sets the stage for that future.

 Short of interactivity, I really don't think we can do better with an
 error message such as this one. The message says "stack overflow", which a
 functional programmer can understand as a process than never appears to be
 ending. It then shows what it's stuck on. Of course, GHC ''could'' show
 the whole cycle as Simon did above, but then the error message would get
 very long, which would then lead to complaints about long error
 messages... which is why I want interactive error messages, so everyone
 gets the length they want.

 As for references to papers: better, more accessible documentation would
 be fantastic. Would you (for any value of "you") care to write some? That,
 too, is a hard and time-consuming task.

 >
 > 1) Why a and a0 are treated as different types in the first version of
 the code? If a ~ a0 then there won't be a loop. In fact, this code is
 coercing a type into itself, which should be trivial.

 `a` there is the type variable used in the input, as given in the type
 signature for `f`. GHC must figure out, though, what the type variable
 should be in the argument to `idSerial` (which is the same as the type
 variable in the argument to `g`, as we learn from `idSerial`'s type
 signature). GHC calls this `a0`. There's no reason for GHC to assume that
 `a` and `a0` should be the same, so it doesn't... and this is the crux of
 the problem.

 >
 > 2) This code works fine if the "Stream" type is defined using "data"
 instead of a "newtype".

 Yes. That's because the loop is induced by the way that GHC "unwraps"
 newtypes in trying to find coercions between types. If you use `data`,
 this unwrapping doesn't happen.

 > About the error message, I think it can be improved.

 These are great, concrete suggestions. Thank you! I agree with Simon that
 accepting the original program would be quite hard (and would require
 fresh computer science research), but rephrasing an error message is very
 doable. I propose we make this ticket about rewriting this error message,
 incorporating your suggestions.

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