#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.
* 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
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. 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