[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages

[GHC]

#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