RE: Wish list: RULES, line number and filenames.
{-# RULES "lookupFM.range check" forall m key . rdMap m key = maybe (lookupFmError #LINE #FILE) id (#lookupFM m key) #-} -- [..] 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). I think Marc wants the line number of the occurrence of rdMap to occur in the error message, not the line number of the definition of the rule "lookupFM.range check". yes, I should have mentioned that you need to use a cpp macro to achieve the desired effect. eg. GHC's "ASSERT" macro: #define ASSERT(e) if (not (e)) then (assertPanic __FILE__ __LINE__) else Cheers, Simon
Re: Wish list: RULES, line number and filenames.
Simon Marlow ([EMAIL PROTECTED]) wrote: : yes, I should have mentioned that you need to use a cpp macro to achieve the : desired effect. eg. GHC's "ASSERT" macro: : :#define ASSERT(e) if (not (e)) then (assertPanic __FILE__ __LINE__) else Cool. I'll try it the next time I have to debug some code. Thanks. Regards, Marc
RE: Wish list: RULES, line number and filenames.
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
Wish list: RULES, line number and filenames.
Dear ghc-team, 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. 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. Just a thought. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 4903578 University College Cork, NUIC | Fax:+353 21 4903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]