
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.
Indeed, this is probably a more logical place for them to live. Recent experience tells me that there is a great potential for import cycles in this area, however. I wish you luck ;)
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.
Sure, I don't see any harm in deriving a Show instances, however. You may want to derive it with standalone deriving so you can then attach a Haddock pointing to the pretty version. e.g., data CallStack = ... -- | See also 'prettyCallStack'. deriving instance Show CallStack
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.
I have also struggled with these sorts of naming decisions. The overloading of the word "show" is a bit problematic. (+1) for "pretty". Cheers, - Ben