replace definition of error with errorWithStackTrace

[Christopher Allen]

I don't think the dwarf information replaces the utility of this proposal,
this proposal, critically, will help the new users who won't know how to
use debugging information. It'll also give people useful first-pass
information for reproducing the error for later, more detailed debugging.

I'd very much like to see this happen if there aren't technical arguments
against it.

--- Chris Allen


On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
>
> if the dwarf information work is landing in 7.10 (as it seems to be),
> perhaps my proposal is moot. But either way, making error "foo" and friend
> more informative by default would be a great thing to make sure happens.
>
> I think we had a clear majority supporting this proposal, but i think
> *some* basic dwarf support got merged in today?
>
> -Carter
>
> On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>>
>> Why don't we use the DWARF information instead? It has no runtime
>> overhead so it can actually be turned on always. It also integrates with
>> all the standard open source tooling.
>>
>> On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>>   +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 at 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.
>>>
>>>
>>>
>>> [1] https://github.com/sol/rewrite-with-location
>>>
>>> [2] https://github.com/sol/rewrite-with-location#explicit-call-stacks
>>>
>>>
>>>
>>> On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen <cma at bitemyapp.com>
>>> wrote:
>>>
>>>  +1 - I would be very happy if this happened.
>>>
>>>
>>>
>>> On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton <mwotton at gmail.com> wrote:
>>>
>>>  having just spent a day tracking down a really uninformative error in
>>> Cabal, I'm all for this.
>>>
>>> On Mon Dec 01 2014 at 11:08:35 Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>
>>> 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!
>>>
>>>
>>>
>>> cheers
>>>
>>> -Carter
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141216/21163e16/attachment-0001.html>