Proposal: add HasCallStack for all partial functions in base

[LuoChen]

@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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190619/08dead5e/attachment.html>