
#9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Let me elaborate a bit more on my concerns here. We currently have two imperfect ways to get a stack trace: profiling and the new -g in 7.10. This is another imperfect way, with different tradeoffs. In particular, you have to modify the source code to take advantage of it (not true of the other two ways). This is fine when it's your own program, but if implicit locations start to be used in common APIs then I'm not sure the extra clutter and user confusion is worth the benefit. It's also very hard to get rid of: APIs have greater longevity than compiler features. Specifically I'm concerned that 1. Users have three imperfect solutions to choose from, which is confusing. 2. Users will want either (a) `head` to have a implicit location, or (b) for there to be a new `headLocated` function that has an implicit location. Both are bad: (a) because head no longer matches the Prelude definition, and users will be confused, and (b) because there are two versions of head, and users will be confused. Moreover, this is a slippery slope: every package author be getting bug reports wanting implicit location versions of all their partial functions. Some users will like this, others will hate it. There will be no clear policy on what to do, and different libraries will adopt different strategies, leading to yet more confusion. 3. We have one more abstraction that must be eliminated by the simplifier to get reliable performance. People who are really concerned about performance will either avoid it, or use `#ifdef` to ensure that they don't have to worry about it. 4. It relies on a very little-used extension (implicit parameters) so those who want to understand what that strange `?location` means have to go and understand implicit parameters. Were it not for this we might be able to deprecate implicit parameters as a feature that didn't turn out to be that useful. Let's think very carefully before we start down this path. It's a really useful feature for end-user code, but the problems arise when we start using it in library APIs. I'd be perfectly OK with this feature (as I mentioned in my earlier comment) as long as it does not infect library APIs except for things that are explicitly undefined, like error, undefined, and so on. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9049#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler