Re: How do I use CallStack?

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