On Mon, Nov 13, 2006 at 12:17:07PM +0000, Simon Peyton-Jones wrote:

The "Maybe.fromJust: Nothing" comes from the library code itself. The "Nat1" part is simply the name of the binary. It give no clue to who called fromJust.

I do not understand the whole idea. First, the same problem is for many functions: head, tail, and others. Also I remember that in some cases GHC reports at run-time something like this: unexhaustive pattern corresponding to the line No ... in the module ... , and this helps a lot. If an error of kind (f _) appears in the GHC library function f, the run-time system, probably recalls who had called for f, because it stores the stack of calls, etc, I do not know ... ?

Finding who called fromJust is an often-requested feature eg tp://hackage.haskell.org/trac/ghc/ticket/960. Currently our best answer to try with the -xc flag (involves recompiling)

The Haskellwiki debugging page could perhaps mention the -xc thing. I had trouble even finding the page from the Haskell.org home page. http://haskell.org/haskellwiki/Debugging

I do not know what is wiki. Is not this sufficient to look into the GHC User Guide for -xc ? So far, I only tried ghc $dmCpOpt -xc --make Nat1 and obtained ghc-6.6: unrecognised flags: -xc Then, tried ./Nat1 +RTS -xc -RTS and obtained not built for: -prof ... So: to re-make all the project for profiling, and then to try ./Nat1 +RTS -pT -xc -RTS ? ----------------- Serge Mechveliani mechvel@botik.ru

...

First, the same problem is for many functions: head, tail, and others.

I often end up using CPP to #define replacements for these, using the __LINE__ and __FILE__ macros to identify the source of the error.

I keep wondering about this every time the topic comes up: 1 Haskell defines function bindings via case, and it requires case to be completed by an implicit default branch calling error; if the error call has source location info, the second part of this works out all right if case occurs explicitly in the source, but the combination of the two parts just seems wrong to me - we are taking a non- exhaustively defined function and make it exhaustive, only to call error when we no longer know about the calling environment (very much like an eta-extension, which promises that there'll be a lambda, even if we don't know whether the computation will ever reach it)! it seems to me that, unless we know a function binding to be exhaustive, at least part of the case should be inlined at the call site. not necessarily the right-hand sides, but certainly the implicit default branch for the case. that way, the error in the default branch would always give somewhat more useful source location info than it does now, or at least the quality of the information would be similar for function bindings and for explicit case (whereas at the moment, function bindings are less well served than explicit cases). 2 as a temporary workaround, we can try to do that unfolding by hand. Ketil uses CPP, which seems to work. I've tried to use GHC's RULES for the same purpose, but found that the source loc info refers to the location of the RULES, not to the location of the expressions that are being replaced. which makes perfect sense normally, but: could RULES perhaps extend the variable environment for the right-hand side of a rule with a binding of "lhsSrcLoc" to the source location information of the left-hand side (provided that such information is still around by the time RULES are being processed?). If that should be possible, we could have RULES for unfolding all those standard non-exhaustive functions at their call sites. just a couple of ideas, claus