[GHC] #11383: CAFs lose sharing due to implicit call stacks
GHC
ghc-devs at haskell.org
Fri Jan 8 17:14:39 UTC 2016
#11383: CAFs lose sharing due to implicit call stacks
-------------------------------------+-------------------------------------
Reporter: simonmar | Owner: gridaphobe
Type: bug | Status: new
Priority: normal | Milestone: 8.0.1
Component: Compiler | Version: 8.0.1-rc1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #11298 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by gridaphobe):
* related: => #11298
Comment:
As you said, this is really just the monomorphism restriction (or in this
case the lack thereof) at work. The two pieces that contribute to this
behavior are:
1. `error` is now overloaded with an implicit parameter, the call-stack.
2. GHC infers implicit parameters (including call-stacks) as needed,
unless there's an explicit signature or the monomorphism restriction
applies.
There's a similar report in #11298, see the two definitions of
`fooHelper`.
We could avoid this (potentially confusing) behavior for the most part by
not inferring call-stacks for top-level definitions. I'm a bit reluctant
to do so because it makes call-stacks less like implicit parameters, and
would require another special case in the type-checker. One of the things
I like about the current version of the call-stack solver is how similar
implicit call-stacks are to regular implicit parameters.
---
I'm actually more concerned about the fact that `-ffull-laziness` changes
the behavior. Does this mean we're caching the first call-stack? That
would be completely wrong; it would be wrong for any implicit parameter.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11383#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list