How do I use CallStack?

[Eric Seidel]

On Mon, Dec 7, 2015, at 06:15, Richard Eisenberg wrote:
> 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?

I think the existing GHC.Stack makes sense, it already exports the -prof
stacks and could re-export the dwarf stacks. Then we'd have a single
access point for all stack trace functionality. 

> 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?

That is correct. I'll advertise the ?callStack convention in the docs. 

> 
> 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.

I have a patch waiting to land that reworks the CallStack solver due to
a similar bug with let binders. I suspect it will fix this bug too, I'll
check it out in my branch. 

> 
> 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
>