Would you (for any value of "you") care to write some? Considering the case "you" == "me", in fact my (tiny) personal contribution to GHC started with documentation. Though I would love to do
#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 harendra): that more unfortunately due to lack of funding I cannot devote time on this.
There's no reason for GHC to assume that a and a0 should be the same, so it doesn't
I am a bit puzzled, initially I thought the same, but then I wondered why GHC treats them the same in the case when `Stream` is not a newtype. So there seems to be a contradiction here, and that is the origin of this issue, because it was working in one case but not in the other, and it was working with explicit type annotation. Let's start with the types `SerialT Identity a` and `SerialT Identity a0`. In the "data Stream" case it would get expanded to: {{{ Stream Identity a Stream Identity a0 }}} Now why does GHC think that these two types are equal if it thinks `a` is not the same as `a0`. I am sure I am missing something, so please help me understand. Maybe after the representations have been simplified GHC is able to unify a with a0. In the problematic case it is never able to simplify them in the first place so the question of unifying never comes. If ultimately `a` can anyway be unified with `a0` then can it unify them before simplifying? In the explicit annotation case perhaps that is what is happening, the programmer has already told GHC that `a` and `a0` are the same, so the simplification starts with that assumption. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15928#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler