Proposal: add HasCallStack for all partial functions in base

[LuoChen]

@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
>>> <https://gist.github.com/luochen1990/bc556d0fc6a1355e5d1bd27a81114870>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190619/05ee2651/attachment.html>