simonmichael
Derive show instances for Journal
The Show instances for Journal currently lose information and try to do some sort of pretty printing/human readable output and even depend on the value of the debug flag. This is not what Show is for imho. I propose to simply derive the Show instances (that works perfectly after you derive a bunch of other instances). This has the advantage, that the dumped Journal is valid Haskell value and can thereby directly used in GHCi. Also it makes debugging easier if there is no information missing.
There are probably some places where it makes sense to keep the human readable output and we can simply create a different function called pprJournal or something like that to create human readable output.
What do you mean when you say "the dumped Journal is valid Haskell value and can thereby directly used in GHCi" ?
The derived Show instance for a journal will be huge, won't it ? Though, with standard Show output we can now use pretty-show, which would help some.
The custom show instances were introduced to reduce that noise, making debugging easier in most cases. Occasionally you really do need to see everything, I guess that's why some special-purpose show functions and debug-level-sensitive show functions were added.
What do you mean when you say "the dumped Journal is valid Haskell value and can thereby directly used in GHCi" ?
Taking the example of showing a Maybe Int, I can just copy paste the output, e.g. Just 1 back into ghci and use it somewhere. If it would try to do some pretty printing that won’t be possible.
The derived Show instance for a journal will be huge, won't it ? Though, with standard Show output we can now use pretty-show, which would help some.
Obviously that depends on the size of the journal, for test cases it’s not so big.
The custom show instances were introduced to reduce that noise, making debugging easier in most cases. Occasionally you really do need to see everything, I guess that's why some special-purpose show functions and debug-level-sensitive show functions were added.
I’m not arguing that there shouldn’t be functions that pretty print output and don’t show all information, I’m arguing that this is not what Show instances are for. If I show something I want to see how the value is represented as a Haskell data type. We could keep the existing behavior but use a separate pretty printing function for that and add Show instances that actually show the Haskell value.
Ok, ie if we use default Show instances it should still be Read-able and pasteable.
I often am debugging things with large real-life journals, that's where I tend to see issues/puzzles first.
I agree that our use of Show is probably inconsistent and a bit unprincipled, and I'd like to have a clearer story, I just haven't yet been able to articulate it. Some questions to be resolved:
In general, should Show output always be Read-able ? You're saying it should, and I think that's the default assumption in Haskell. Pro:
- you can use it as a serialisation format
- you can paste saved values into GHCI sessions
- you can (more often) format it nicely with pretty-show
Con:
- output gets very verbose and tends to obscure what's important when debugging
What is Show currently used for in hledger ?
- debugging
- rendering normal user output (decreasingly, but perhaps still a few cases)
- in error messages ?
In hledger, should Show be used for rendering user output ? no
In error messages ?
For debugging ? Pro:
- Show instances already exist for most things; building a parallel debug class might be a lot of needless work ?
- pretty-show can format it nicely for you
- we don't currently need it for anything else
What is useful for debugging ?
- multiple levels of detail, selectable at runtime/ghcicommandtime as far as possible
- nicely formatted output
- easy creation of custom output formats exposing things of interest