<div dir="ltr">If you're debugging GHC, I've recently added pprSTrace ::  (?location :: CallStack) => SDoc -> a -> a in Outputable. It's been a great help for me in understanding where the calls were coming from. You can just use it without importing anything extra, and when you want more context you just add (?location :: CallStack) => to the function you're debugging, plus necessary imports (GHC.Stack) and extensions (ImplicitParams). I think it improved my workflow by an order of magnitude.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-07 6:39 GMT+00:00 Eric Seidel <span dir="ltr"><<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<br>
Sorry for all of the confusion, it seems the docs do indeed need some<br>
love!<br>
<span class=""><br>
On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:<br>
> That looks like exactly what I want. Thanks.<br>
><br>
> There remain two mysteries:<br>
> - I thought that CallStacks were a new feature that would come with GHC<br>
> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the<br>
> docs even say (wrongly, evidently) that it's in base since 4.9.<br>
<br>
</span>They were originally merged into 7.11, but were backported to the<br>
official 7.10.2 release due to popular demand. It appears the @since<br>
annotation wasn't updated correspondingly.<br>
<span class=""><br>
> - That function seems missing in HEAD. Or maybe it moved. A little<br>
> searching says it *did* move, to GHC.Exception.<br>
<br>
</span>In HEAD we are now using CallStacks for error and undefined, which was<br>
not the case for the 7.10.2 release. This means the type needs to be<br>
defined much earlier in base, before we even have enough functionality<br>
to write a sensible formatter. showCallStack currently lives in<br>
GHC.Exception because that's where it's used, but that's not a good<br>
reason... I'll take another look at moving it back to GHC.Stack.<br>
<span class=""><br>
> Well, my problem is solved. But I think the documentation needs a pass<br>
> here. And is there a reason not to have a Show instance?<br>
<br>
</span>I usually only use compiler-derived Show instances so that Read<br>
automatically works, as well as some nice formatting libraries like<br>
<a href="http://hackage.haskell.org/package/pretty-show" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/pretty-show</a> for debugging. For<br>
pretty-printing like showCallStack I prefer a standalone function or a<br>
separate type-class.<br>
<br>
If the name "showCallStack" suggests the compiler-derived output, we<br>
could change it to something like "prettyCallStack" or<br>
"formatCallStack", I don't have a strong opinion there.<br>
<br>
Thanks for the comments!<br>
<span class="HOEnZb"><font color="#888888">Eric<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>