Proposal: add HasCallStack for all partial functions in base

Fri Jun 21 18:42:37 UTC 2019

agreed, the -xc flag is an underused debugging tool, and making that easier
to work with / front and center is probably a high impact approach

On Wed, Jun 19, 2019 at 11:11 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> I find this thread a bit concerning. In my opinion the current best
> way to get call stacks on exceptions is with `-xc`. Adding runtime
> overhead to every user program is not acceptable.
>
> `HasCallStack` is useful in libraries such as shake or hspec which use
> them to good effect to provide callstacks to users on exceptions
> controlled by the libraries.
>
> There is an argument that it would be good to disentangle `-xc` from
> `prof` but you would still have to compile `base` in this way which
> instruments these partial functions (as a user can not do it herself).
> I'm not too sure on the details but I don't think -xc uses any
> information from the profiling header so the fact it's connected with
> -prof seems more like convenience than necessity.
>
> Matt
>
> On Wed, Jun 19, 2019 at 3:48 PM LuoChen <luochen1990 at gmail.com> wrote:
> >
> > @eric Thanks, this withFrozenCallstack  works as expected! Maybe we can
> provide a compiler option to automatically insert `withFrozenCallstack`
> somewhere when importing other packages, so that we can focus on current
> working package's call stack, just like david said.
> >
> > Eric Seidel <eric at seidel.io> 于2019年6月19日周三 下午7:25写道：
> >>
> >> You can use withFrozenCallstack to avoid adding new entries to the
> stacktrace (but you still need HasCallstack constraints all the way down to
> error, of course).
> >>
> >>
> http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stack.html#v:withFrozenCallStack
> >>
> >> Sent from my iPhone
> >>
> >> On Jun 19, 2019, at 00:41, LuoChen <luochen1990 at gmail.com> wrote:
> >>
> >> @david It seem that we doesn't have such a mechanism yet. AFAIK with
> `HasCallStack` we can only build a call stack from the deepest bottom.
> >>
> >> Is it possible to build a call stack from middle of the call chain to
> the top, without containing the deepest parts?
> >> e.g. f1 -> f2 -> f3 -> error  (f -> g means f call g) , is it possible
> to build a call stack only contains f1 and f2, without f3 and error?
> >>
> >> David Feuer <david.feuer at gmail.com> 于2019年6月18日周二 上午3:57写道：
> >>>
> >>> As I recall, the main things to watch out for, performance-wise, are
> recursive definitions. When we throw an error from a library function, we
> *typically* mean that the caller made a mistake. We don't want to build up
> the call stacks we'd need to debug the library function itself, unless
> we're actually doing so (in which case we can edit it in, of course).
> >>>
> >>> On Mon, Jun 17, 2019, 1:09 PM Edward Kmett <ekmett at gmail.com> wrote:
> >>>>
> >>>> Re: your code. This is passing the callStack to each instance and
> dropping it on the floor for the cases where you ignore the constraint.
> >>>>
> >>>> I’m starting to warm to the idea of putting HasCallStack constraints
> on the obviously partial combinators in base if we can demonstrate that the
> performance impact isn't bad in practice, and even really, to some extent
> if there is a somewhat middling impact on the performance of code that
> leans on these hard to debug combinators, so long as the performance of
> their more total siblings remains unaffected. The impact on the perceived
> debuggability of Haskell seems _likely_ to significantly outweigh the
> performance concerns.
> >>>>
> >>>> Heck, off of the HEAD of cabal, which we’re encouraging folks to
> build to play with the ghc 8.8.1 alpha, just today we ran into an issue
> where the very build system we are using spat out an oh so informative
> “Prelude.foldr1: Empty list” when using a pkgconfig-depends stanza that
> didnt include any explicit bounds.
> >>>>
> >>>> It seems worth implementing and measuring quite how bad the impact
> would be before pulling the trigger for good. The impact should be
> reasonable if the constraints only really live right at the outside of base
> though, then users can choose to propagate the constraint further outwards,
> just like they get to do with “error” today.
> >>>>
> >>>> Slightly more controversially, MonadFail’s fail could be similarly
> modified with near zero user facing impact other than a bit of additional
> static info flowing to explicit callstacks to make it take a HasCallStack
> constraint. The code in existing instances would all still work. This one I
> think would need more benchmarking though, as recovering from a fail is a
> far “lighter” affair than catching an exception, but I’d be happy to raise
> it to the CLC as a question, especially if we can get benchmarks in hand.
> >>>>
> >>>> —Edward
> >>>>
> >>>>
> >>>> On Jun 17, 2019, at 4:06 PM, LuoChen <luochen1990 at gmail.com> wrote:
> >>>>
> >>>> I have just confirmed that we can specify HasCallStack separately for
> different instance of same typeclass, and here is the test code.
> >>>>
> >>>>
> >>>> Oliver Charles <ollie at ocharles.org.uk> 于2019年6月17日周一 上午3:02写道：
> >>>>>
> >>>>> Surely then the call stack is only foldr1, and not foldr1's callsite?
> >>>>>
> >>>>> On Sun, 16 Jun 2019, 8:27 pm Henning Thielemann, <
> lemming at henning-thielemann.de> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Sun, 16 Jun 2019, Simon Jakobi wrote:
> >>>>>>
> >>>>>> > >  I think only the partial implementations should get that
> constraint.
> >>>>>>
> >>>>>> > Oops, I had the misconception that one couldn't add a HasCallStack
> >>>>>> > constraint to method implementations.
> >>>>>>
> >>>>>> I think you have to declare:
> >>>>>>
> >>>>>> instance Foldable [] where
> >>>>>>     foldl1 = foldl1List
> >>>>>>
> >>>>>> foldl1List :: HasCallStack => (a->a->a) -> [a] -> a
> >>>>>> foldl1List = ...
> >>>>>>
> >>>>>> Would this work?_______________________________________________
> >>>>>> Libraries mailing list
> >>>>>> Libraries at haskell.org
> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>>
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>>
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190621/4f7a6d1c/attachment.html>