RE: Wish list: RULES, line number and filenames.

2000-08-10 Thread Simon Marlow

   {-# 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.

2000-08-10 Thread 'Marc van Dongen'

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.

2000-08-09 Thread Simon Marlow


 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.

2000-08-04 Thread Marc van Dongen

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]