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