#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