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