<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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). <div><br></div><div><a href="http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stack.html#v:withFrozenCallStack">http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stack.html#v:withFrozenCallStack</a><br><br><div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Jun 19, 2019, at 00:41, LuoChen <<a href="mailto:luochen1990@gmail.com">luochen1990@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>@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.<br></div><div><br></div>Is it possible to build a call stack from middle of the call chain to the top, without containing the deepest parts?<div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> 于2019年6月18日周二 上午3:57写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2019, 1:09 PM Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div><br></div><div><span style="background-color:rgba(255,255,255,0)">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. </span><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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.</span><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)">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.</span></div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)">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.</span></div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div dir="ltr"><span style="background-color:rgba(255,255,255,0)">—Edward</span></div><div dir="ltr"><br></div></div></div><div dir="ltr"><br>On Jun 17, 2019, at 4:06 PM, LuoChen <<a href="mailto:luochen1990@gmail.com" rel="noreferrer" target="_blank">luochen1990@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail-m_94468591495292676m_6575406126497324923markdown-here-wrapper"><p style="margin:0px 0px 1.2em">I have just confirmed that we can specify <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">HasCallStack</code> separately for different instance of same typeclass, and <a href="https://gist.github.com/luochen1990/bc556d0fc6a1355e5d1bd27a81114870" rel="noreferrer" target="_blank">here</a> is the test code.</p>
<div title="MDH:SSBoYXZlIGp1c3QgY29uZmlybWVkIHRoYXQgd2UgY2FuIHM8c3BhbiBzdHlsZT0iY29sb3I6IHJn
YigzNiwgNDEsIDQ2KTsgZm9udC1mYW1pbHk6IC1hcHBsZS1zeXN0ZW0sIEJsaW5rTWFjU3lzdGVt
Rm9udCwgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssIEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYs
ICZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90
OywgJnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7OyBmb250LXNpemU6IDE0cHg7Ij5wZWNpZnkg
YEhhc0NhbGxTdGFja2Agc2VwYXJhdGVseSBmb3IgZGlmZmVyZW50IGluc3RhbmNlIG9mIHNhbWUg
dHlwZWNsYXNzLCBhbmQgW2hlcmVdKDwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpc3QuZ2l0aHVi
LmNvbS9sdW9jaGVuMTk5MC9iYzU1NmQwZmM2YTEzNTVlNWQxYmQyN2E4MTExNDg3MCI+aHR0cHM6
Ly9naXN0LmdpdGh1Yi5jb20vbHVvY2hlbjE5OTAvYmM1NTZkMGZjNmExMzU1ZTVkMWJkMjdhODEx
MTQ4NzA8L2E+KSBpcyB0aGUgdGVzdCBjb2RlLg==" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Oliver Charles <<a href="mailto:ollie@ocharles.org.uk" rel="noreferrer" target="_blank">ollie@ocharles.org.uk</a>> 于2019年6月17日周一 上午3:02写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Surely then the call stack is only foldr1, and not foldr1's callsite?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 16 Jun 2019, 8:27 pm Henning Thielemann, <<a href="mailto:lemming@henning-thielemann.de" rel="noreferrer" target="_blank">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Sun, 16 Jun 2019, Simon Jakobi wrote:<br>
<br>
> > I think only the partial implementations should get that constraint.<br>
<br>
> Oops, I had the misconception that one couldn't add a HasCallStack <br>
> constraint to method implementations.<br>
<br>
I think you have to declare:<br>
<br>
instance Foldable [] where<br>
foldl1 = foldl1List<br>
<br>
foldl1List :: HasCallStack => (a->a->a) -> [a] -> a<br>
foldl1List = ...<br>
<br>
Would this work?_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a></span><br></div></blockquote></div></div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a></span><br></div></blockquote></div></body></html>