[GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks
GHC
ghc-devs at haskell.org
Thu Feb 14 13:08:09 UTC 2019
#11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep
leaks
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: (none)
Type: bug | Status: new
Priority: highest | Milestone: 8.6.1
Component: Compiler | Version: 7.10.3
Resolution: | Keywords:
| LevityPolymorphism
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Yikes. I have just wasted 30 minutes (in Core dumps) figuring out why a
type printed as
{{{
forall a b. Eq a => blah
}}}
didn't match a term
{{{
/\ a. \(d :: Eq a). blah
}}}
Turns out that the real type is `forall a. Eq a => forall b. blah`, but
the pretty printer silently moves the foralls to the top. This is done in
`splitIfaceSigmaTy` in the patch in comment:13.
It might be ''just'' arguable to move the foralls around for ''user''
types. E.g in test `ghci025` we now report
{{{
return :: Monad m => a -> m a
}}}
whereas previously it was
{{{
return :: Monad m => forall a. a -> m a
}}}
But we definitely should not do this in Core printouts.
I also noticed that in the output for `ghci025` we have
{{{
c3 :: forall a b a. C a b => a -> b
}}}
The repeated 'a' is terrible!
So I'm re-opening this ticket to ask: do we want to swizzle the foralls to
the top, even in user printout?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11786#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list