#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 simonpj): Thanks. I've added some comments to Phab:D578. Here are some other thoughts: * 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. * 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)] }}} * 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.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9049#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler