RE: Proposal: Improved error message of "Error in array index"
On 08 November 2005 09:19, John Meacham wrote:
jhc has a SRCLOC_ANNOTATE pragma to solve just this problem
here is the relevant part of the docs:
* SRCLOC_ANNOTATE pragma. This is a generalization of GHCs assert magic. A function which is given an SRCLOC_ANNOTATE pragma will be replaced with an alternate version that takes the functions use site as an argument. This allows error messages to be in terms of where said function was used. The alternate function is named [function]_srcloc_ann__ and must be in the same module as the original function. Jhc does no checking to ensure both functions have the same effect, it is up to the user to ensure that. An example is
Nice - though it would be even better to provide the required functionality automatically. One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*, giving you a proper backtrace for any exception, at least for the parts of the call stack that are interpreted. We don't care about the cost too much - interpreted code is a lot slower than compiled already, and it would only be a small constant factor. I think this would be a huge win for debuggability. And a nice project for anyone who wants to hack on the GHC internals - though not a small task by any means. Cheers, Simon
On Tue, Nov 08, 2005 at 11:12:09AM -0000, Simon Marlow wrote:
Nice - though it would be even better to provide the required functionality automatically.
I am not sure that is the case. I think library authors would be better suited to provide meaningful error messages and decide when propegating the srcloc would be useful. also, experienced haskell programs tend not to write partial functions to begin with, relying on pattern matching which is often more efficient and automatically gives a localized error message on failure.
One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*, giving you a proper backtrace for any exception, at least for the parts of the call stack that are interpreted. We don't care about the cost too much - interpreted code is a lot slower than compiled already, and it would only be a small constant factor. I think this would be a huge win for debuggability. And a nice project for anyone who wants to hack on the GHC internals - though not a small task by any means.
personally, I rarely find the stack dump very useful at all (though I always have high hopes). perhaps I have just had bad experiences with it, but it can often be uninformative or even misleading. John -- John Meacham - ⑆repetae.net⑆john⑈
Simon Marlow wrote:
One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*, giving you a proper backtrace for any exception, at least for the parts of the call stack that are interpreted. We don't care about the cost too much - interpreted code is a lot slower than compiled already, and it would only be a small constant factor. I think this would be a huge win for debuggability. And a nice project for anyone who wants to hack on the GHC internals - though not a small task by any means.
The cost-centre machinery is very close to the machinery necessary to generate the trace of the Haskell tracer Hat. If you implement one, with small modifications you get the other. The overhead for both is basically the same, except that the larger Hat trace needs to be written to file. Ciao, Olaf
participants (3)
-
John Meacham -
Olaf Chitil -
Simon Marlow