How do I use CallStack?

[Richard Eisenberg]

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 <eric at seidel.io> wrote:

> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs