Additionally, Another  way to include line number information and to improve readability of the degugging code  is to add "verify"  as an  "assert" with flipped parameters so we can write:

let x= head xs                 `verify` (not $ null xs)

So the assertions appear on the right , separated from the  rest of the code.

instead of

let x= assert (not $ null xs) xs





2013/2/26 Gershom Bazerman <gershomb@gmail.com>
On 2/25/13 9:42 AM, Simon Peyton-Jones wrote:

I’m afraid the rewrite-rule idea won’t work.  RULES are applied during optimisation, when tons of inlining has happened and the program has been shaken around a lot. No reliable source location information is available there.

 

See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit it.

 

One idea I had, which that page does not yet describe, is to have an implicit parameter,
something like ?loc::Location, with

          errLoc :: ?loc:Location => String -> a

          errLoc s = error (“At “ ++ ?loc ++ “\n” ++ s)

 

This behave exactly like an ordinary implicit parameter, EXCEPT that if there is no binding for ?loc::Location, then the current location is used.  Thus


I like the general approach of this proposal quite a bit. I'd very much like Location to be not just a string, but a record type. Ideally we could recover not just module name, line and character, but also the name of the function that takes the location. This would eliminate an entire swath of use-cases for Template Haskell. For example, I've worked out a template-haskell-free version of the Cloud Haskell closure API, which hopefully is getting merged in at some point. The major drawback it has is that the user is required to provide a globally-unique identifier for each closure, ideally stable across compilations. The current TH code solves this by grabbing the function and module name. If we could get direct access to these things without requiring template haskell, that would be quite nice. Other types of RPC libraries I've worked on could similarly benefit from this.

Cheers,
Gershom



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.