[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 request   |                  Status:  patch
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.8.2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:  Phab:D578
-------------------------------------+-------------------------------------

Comment (by gridaphobe):

 Replying to [comment:23 simonpj]:
 >  * Could you modify [wiki:ExplicitCallStack/ImplicitLocations] to
 describe the exact specification of what you propose?   For example, the
 design means that there are two new types in the `base` library, defined
 in `GHC.Location`:
 >    * `SrcLoc` (for a source location)
 >    * `Location` (for a stack of source locations)
 >    Both are abstract, so you can't make a new `SrcLoc` or `Location`;
 only GHC can do that. Is that what we want?
 >
 >  * You can add a section on open questions too, for things you aren't
 sure about.

 Done. It's not an open question per se, but folks following this ticket
 may want to look at the second bullet point under Implementation Details.
 I'm a bit uneasy about veering that far away from the standard behavior of
 ImplicitParams, but I think it's worth considering at least.

 >  * I'm very keen that `SrcLoc` is used also by the `Typeable` library
 (and any other reflection libraries too).  Currently
 `Data.Typeable.Internals` defines `TyCon` which contains
 package/module/name information, but it should just use a `SrcLoc`.  We
 are proposing to redesign `Typeable` anyway (see [wiki:Typeable]) so we
 can do this `SrcLoc` stuff at the same time
 >
 >  * Given this broader use, is `Location` the right name?  It's really
 more like a `SrcLocStack`.
 >
 >  * The stack would be even better if it said something like "foo called
 at <location>" rather than just "<location>".  That would be easy enough
 to implement (the information is in the `CtOrigin` of the constraint), but
 again the data type would need to be elaborated a bit, something like
 > {{{
 > data Location = Location [(String, SrcLoc)]
 > }}}

 In anticipation of this I've renamed `Location` to `CallStack`, but it
 looks like the `CtOrigin` that we get may not provide enough info. In my
 test-case at least, I'm getting a `TypeEqOrigin`, which isn't particularly
 helpful.

 >  * At a grungy level, I wonder about all the copies of the same module-
 name and file-name strings.  Maybe the desugarer should just generate one
 copy and use it?  Or maybe CSE should gather them up (I don't think it
 does so at the moment.)

 Hmm, if this is an issue my instinct would be that CSE should be
 responsible for cleaning up the duplicate strings. It seems to fit with
 the Core philosophy of having the simplifier clean up after the various
 other passes, and may provide benefits outside of these IP CallStacks too.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler