+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2].
IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.
I think we have something of a consensus forming around
https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, see #9049. It’s simple, non-invasive, and predicatable. It does need someone to implement it though. Simon Hengel is thinking about implementing it. (He is the one who also
suggested “rewrite with location”).
So I think we are stalled not so much on design but on implementation.
Simon
From: Libraries [mailto:libraries-bounces@haskell.org]
On Behalf Of Michael Snoyman
Sent: 01 December 2014 05:33
To: Christopher Allen; Mark Wotton
Cc: Haskell Libraries
Subject: Re: replace definition of error with errorWithStackTrace
+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2].
IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.
On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen <cma@bitemyapp.com> wrote:
+1 - I would be very happy if this happened.
On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton <mwotton@gmail.com> wrote:
having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.
http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorWithStackTrace
has been in GHC for for >=1 major version,
and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!
I think this change would benefit many!
My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done
in a single small patch that could easily be swapped out for that improved approach once it lands.
discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries