There's no reason to produce these every time we need to evidence.
- rGHC Glasgow Haskell Compiler
No Unit Test Coverage
- Build Status
Buildable 14220 Build 21922: [GHC] Linux/amd64: Patch building Build 21921: [GHC] OSX/amd64: Continuous Integration Build 21920: [GHC] Windows/amd64: Continuous Integration Build 21919: arc lint + arc unit
Hmm, I'm not sure about this. This patch will force us to unpack the Module strings every time they're used, which would be memoized in the current code.
Furthermore, the unpacking should be shared between multiple SrcLocs in a module (at least as of D1259).
Seems like we're shoving work from compile- to run-time, which doesn't seem like the right move.
But do we really expect string unpacking from CallStacks to be a bottleneck? In fact, I would have thought that we would generally *want* to unpack each time since we are more likely to deforest the intermediate list.
Good catch, I thought we had only exported an abstract type from GHC.Stack, but it turns out we export the field selectors there too.
Should we present only an abstract type to the world?
Yes, a fair point.
Yes, this is unfortunate. One option here would be to rename the data constructor and instead expose a pattern synonym, but it feels a bit yucky. As API breakage goes I think this is a pretty innocuous case; I suspect most people are just showing these things.
Moreover, we have been meaning to consolidate our Module and location types for a long time now; this is a good step in that direction.
I don't quite grok this. What do you mean?