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 myErr :: ?loc:Location => Int -> a myErr n = errLoc (show n) foo :: Int -> int foo n | n<0 = myErr n | otherwise = ...whatever... When typechecking ‘foo’ we need ?loc:Location, and so the magic is that we use the location of the call of myErr in foo. Simon From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Kjeldaas Sent: 25 February 2013 12:16 To: Simon Hengel Cc: Haskell Cafe Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel <[email protected]<mailto:[email protected]>> wrote: On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote: > I think there is no need to have a separate REWRITE_WITH_LOCATION > rule. What if the compiler instead rewrites 'currentLocation' to the > current location? Then you'd just define the rule: > > {-# REWRITE "errorLoc" error = errorLoc currentLocation #-} REWRITE rules are only enabled with -O. Source locations are also useful during development (when you care more about compilation time than efficient code and hence use -O0). So I'm not sure whether it's a good idea to lump those two things together. I could imagine that source locations being useful when debugging rewrite rules for example. I think your argument makes sense, but why not fix that specifically? {-# REWRITE ALWAYS "errorLoc" error = errorLoc currentLocation #-} Alexander
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
