And sorry if my tone on those emails was a bit snarky. It was late... though snarkiness at any hour is unwelcome. :) I understand the concerns about the Show instance, though I have no opinion about the name of the pretty-printer. My only request is that the pretty-print function is easily discoverable. In my case, I never would have looked in GHC.Exception, because I wasn't throwing (or dealing with) any exceptions. Perhaps a new module GHC.CallStack that bundles everything together and is the official export point? Bartosz, thanks for alerting me about pprSTrace. But I now realize that there is an annoying free variable in all of this: the name of the CallStack. Consider this:
foo :: (?location :: CallStack) => ... foo = pprSTrace ... -- pprSTrace uses ?location bar :: (?callstack :: CallStack) => ... bar = foo
If I understand correctly, I'll get a redundant constraint warning on bar, and I won't see bar's location in the output from pprSTrace. In other words, the choice for the CallStack name is infectious. I have no problem with ?location, but it's different from `error`'s choice (?callStack) and this choice seems to matter. Should we choose a common name? Advertise this widely with the docs for CallStack? (I imagine it's best for the ecosystem if everyone, everywhere uses the same name.) Or do I understand the feature wrongly?
As quite a separate point from above, I may have found a bug: I put a (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained about a redundant constraint on rewriteEqEvidence, and indeed its call information wasn't propagated. rewriteEqEvidence uses pattern guards and do-notation, but that shouldn't muck with CallStack, should it? I've not tried to reproduce this in a smaller test case.
Many thanks,
Richard
On Dec 7, 2015, at 1:39 AM, Eric Seidel
Hi Richard,
Sorry for all of the confusion, it seems the docs do indeed need some love!
On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
That looks like exactly what I want. Thanks.
There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.
They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly.
- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.
In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack.
Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?
I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class.
If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there.
Thanks for the comments! Eric _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs