This upgrades Account to enable it to store a multiperiod balance, with
a separate balance for each date period. This enables it do the hard
work in MultiBalanceReport.
Some new types are created to enable convenient operation of accounts.
- `BalanceData` is a type which stores an exclusive balance, inclusive
balance, and number of postings. This was previously directly stored
in Account, but is now factored into a separate data type.
- `PeriodData` is a container which stores date-indexed data, as well as
pre-period data. In post cases, this represents the report spans,
along with the historical data.
- Account becomes polymorphic, allowing customisation of the type of
data it stores. This will usually be `BalanceData`, but in
`BudgetReport` it can use `These BalanceData BalanceData` to store
both actuals and budgets in the same structure. The data structure
changes to contain a `PeriodData`, allowing multiperiod accounts.
Some minor changes are made to behaviour for consistency:
- --declared treats parent accounts consistently.
- --flat --empty ensures that implied accounts with no postings are not displayed, but
accounts with zero balance and actual postings are.
Older ghc versions should also still build cleanly (tested with 9.8 so far).
I don't like enabling CPP in so many modules but it's easier that
figuring out how to do it with base-compat; hopefully no noticeable
compilation impact.
When reports want to render amounts without commmodity symbols,
they must now use AmountDisplayOpts' new displayCommodity flag.
(Previously it was a side effect of setting displayCommodityOrder.)
That 1.31 change was advertised as being for the print command only,
but it affected all commands. Now it affects only print and other
"print-like" commands (ie all commands that show whole journal entries
that we might want to re-parse).
Also three classes of hledger output, and how they modify the
commodity display styles' digit group marks and decimal marks
to suit different consumers, have been identified and documented
(under REPORTING CONCEPTS).
With valuation now preserving more decimal digits, roi could show
excessively precise decimals if there was no known display precision
for the valuation commodity. Now in that situation it limits the
precision to a maximum of 8 digits.
This and the preceding commits were "work in progress" that got out of control.
There's more to do, but this one brings these precision-related improvements
(at least):
When "infinite decimals" arise, they are now generally shown with
8 decimal digits rather than 255.
print and prices no longer add trailing decimal zeros unnecessarily.
Some code has been refactored or given more debug output.
All tests have been updated to match the recent changes.
- The prices comand now more accurately lists the prices that hledger
uses when calculating value reports (similar to what you'd see with
eg `hledger bal -V --debug=2`).
- The prices command's --infer-reverse-prices flag was confusing since
we always infer and use reverse prices; it has been renamed to --show-reverse.
- --infer-market-prices and --show-reverse combine properly.
- --show-reverse now ignores all zero prices rather than giving an error.
- Reverse prices (which can be infinite decimals) are now displayed
with at most 8 decimal digits (rather than the internal precision of
255 digits).
- Filtering prices by cur: or amt: now works properly.
- Price amounts are styled, but all decimal digits are shown.
Cost/value conversion now applies the standard display style, and
sets the display precision equal to the internal decimal precision
(or 8 if the decimal appears to be infinite).
This means value reports and especially `print -V` now show amounts
with more accurate and standard style and precision.
New tests have been added describing and explaining various
style/precision behaviours in print cost/value reports.
Changes to enable more control of "rounding" behaviour
(ie, choosing display precisions for amounts).
This reverts 1.31's change of asprecision, making it a non-Maybe
again, and adds a new asrounding field providing more control over how
a target display precision is applied to existing amounts (two options
for now, more later). Functionality is in an interim state (reports do
no rounding).
Eg "1,000" (with , as a thousands separator and no decimal digits) is
now displayed with a decimal mark: "1,000.".
"1 000" (where space is a thousands separator) is less ambiguous,
but we do the same thing (eg "1 000.") for consistency, and also to
help disambiguate when forgetting to quote a numeric commodity symbol
(eg "1234 0" where 1234 is a symbol that should have been in double quotes).
This simplifies the code for styling amounts with or without precision.
But it complicates the semantics (Nothing is useful only when setting style).
Not sure if it's the best way.
print now shows zero posting amounts with their original commodity
symbol and the corresponding style (instead of stripping the symbol).
If an inferred amount has multiple zeroes in different commodities,
a posting is displayed for each of these.
Possible breaking changes:
showMixedAmountLinesB, showAmountB, showAmountPrice now preserve
commodityful zeroes when rendering. This is intended to improve print output,
but it seems possible it might also affect balance and register reports,
though our tests show no change in those.
