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

Michael Snoyman michael at snoyman.com
Tue Feb 26 13:24:56 CET 2013


On Tue, Feb 26, 2013 at 12:06 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  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.
>
>
I personally have very little opinion about how this feature is
implemented. But would this approach implement the shallow trace, or the
full stack trace?

Michael


>  ****
>
> 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>
> 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] *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> 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
> 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/37cca2bc/attachment.htm>


More information about the Haskell-Cafe mailing list