Do you mean that the proposal itself won't work, or specifically implementing this features in terms of existing rewrite rules won't work?
I meant the latter. I'll admit to ignorance on the internals of GHC, but it seems like doing the shallow source location approach would be far simpler than a full trace. I'd hate to lose a very valuable feature because we can't implement the perfect feature. I agree with that sentiment. But in fact I suspect that getting a stack is little or no harder than the shallow thing. My "implicit parameter" suggestion was trying to re-use an existing feature, with a small twist, to do what you want, rather than to implement something brand new. Simon From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of Michael Snoyman Sent: 25 February 2013 18:19 To: Simon Peyton-Jones Cc: Alexander Kjeldaas; Simon Hengel; Haskell Cafe Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> 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. Do you mean that the proposal itself won't work, or specifically implementing this features in terms of existing rewrite rules won't work? See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit it. One thing I'd disagree with on that page is point (3). While it's certainly nice to have a full stack trace, implementing just shallow call information is incredibly useful. For logging and test framework usages, it in fact completely covers the use case. And even for debugging, I think it would be a massive step in the right direction. I'll admit to ignorance on the internals of GHC, but it seems like doing the shallow source location approach would be far simpler than a full trace. I'd hate to lose a very valuable feature because we can't implement the perfect feature. 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: haskell-cafe-boun...@haskell.org<mailto:haskell-cafe-boun...@haskell.org> [mailto:haskell-cafe-boun...@haskell.org<mailto:haskell-cafe-boun...@haskell.org>] 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 <s...@typeful.net<mailto:s...@typeful.net>> 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 Haskell-Cafe@haskell.org<mailto:Haskell-Cafe@haskell.org> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
