> At the moment I think it is only possible that
> error messages about functions can refer to line
> numbers and names of source files at the points
> of *definition* of these functions. These error
> messages are the ones that ghc automatically
> generates when there is a pattern matching error.
>
> I think it would be useful to have error messages
> about functions that refer to the line number and
> the name of the source files at the moment these
> functions are *used*. This would make it a lot
> easier to locate errors.
You're right in saying that errors can be generated at certain points in the
source file, but these points (the beginning of a definition, a case branch,
a type signature, a guard, an 'if' expression, etc.) have nothing to do with
definition vs. call-sites. If you have an example of an error message that
is being wrongly attributed, could you send it please?
> I also think it would be handy to give the user
> more control about line numbers and file names.
> One possibility (modulo newlines in the RULES section)
> would be an extension as follows:
>
> {-# RULES
> "lookupFM.range check" forall m key . rdMap m key =
> maybe (lookupFmError #LINE #FILE)
> id
> (#lookupFM m key)
> #-} -- ^^^^^^^^
>
> lookupFmError line file
> = error $ concat ["lookupFM :: key not in range in line
> ",line," in ",file]
>
> The function #lookupFM would be the ``real''
> lookupFM function. The idea is that after debugging
> of a function one can just disable a rule in the
> RULES section.
Actually, when using cpp, the __LINE__ and __FILE__ macros should expand to
the right thing (this is what GHC itself uses to generate accurate locations
for assertion failures).
Cheers,
Simon
