[Haskell-cafe] RFC: rewrite-with-location proposal

[Simon Peyton-Jones]

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.snoyman at gmail.com [mailto:michael.snoyman at 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 <simonpj at microsoft.com<mailto:simonpj at 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-bounces at haskell.org<mailto:haskell-cafe-bounces at haskell.org> [mailto:haskell-cafe-bounces at haskell.org<mailto:haskell-cafe-bounces at 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 <sol at typeful.net<mailto:sol at 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 at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130226/351a6386/attachment.htm>