It's amazing how you can build, document, support and fix a thing for
years and not know what exactly it does. Directives are tricky.
Here is a pretty accurate description of their current behaviour,
determined by testing.
For Data/Dates.hs in particular:
- Changed `SimpleTextParser` to `TextParser m` for all parsers
- Changed `string` to the case-insensitive `string'` to match the
behaviour of `T.toLower` found in `parsePeriodExpr`
- export `periodexprp` for "direct" use
... for displaying the source line on which parse errors occured
Over the following set of commits, I will to refactor the parsers to
obviate the `ExceptT String` layer of the `ErroringJournalParser` type
so that all parse errors go through Megaparsec's parse error machinery.
base-compat-batteries provides the same API across more ghc versions
than base-compat does, at the cost of more dependencies. Eg it exports
Prelude.Compat ((<>)) with ghc 7.10/base 4.8, which we expect.
My belief is that several of our deps already require it so the added
cost is not too great. We should probably go back to base-compat when
possible though, eg when we stop supporting ghc 7.10.
The new version of our package set apparently contains both base-compat and
base-compat-batteries in its transitive closure. This breaks the doctest suite,
which just imports everything into scope when the tests are run, thereby making
module names like Prelude.Compat ambiguous.
We don't need to import Data.Monoid because Prelude.Compat exports "<>"
already. In fact, importing that module causes build failures:
Hledger/Read/Common.hs:725:62: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Sem.<>’,
imported from ‘Prelude.Compat’ at Hledger/Read/Common.hs:97:1-39
(and originally defined in ‘Data.Semigroup’)
or ‘Data.Monoid.<>’,
imported from ‘Data.Monoid’ at Hledger/Read/Common.hs:110:1-18
Fixes https://github.com/simonmichael/hledger/issues/794.
- Rationale:
- The information necessary for applying exponents to a number is more
explicitly represented in the inputs to `fromRawNumber` than in the outputs
- This way, `exponentp` may simply return an `Int`
- Purpose: to reduce the verbosity of the previous implementation
- Split off `AmbiguousNumber` into its own type
- Introduce a function `AmbiguousNumber -> RawNumber` explicitly capturing the
disambiguation logic
- Reduce the number of remaining constructors in `RawNumber` to just two,
`WithSeparator` and `NoSeparator`
- The choice to distinguish by the presence of digit separators is motivated
by the need for this information later on when disallowing exponents on
numbers with digit separators
- Extracts the handling of signs out of `fromRawNumber` and into `signp` itself
- Rationale: The sign can be applied independently from the logic in
`fromRawNumber`
It now works slightly differently. Eg:
- <unbudgeted>'s subaccounts are hidden by default
- --show-unbudgeted shows all unbudgeted accounts, including subaccounts of budgeted parents
- --show-unbudgeted doesn't affect the grouping under <unbudgeted>
IMHO it's a nice simplification and increase in consistency, while still meeting the original intent.
Accounts which have no budget goals within the report period are now
grouped under <unbudgeted> - not just accounts with no budget goals ever.
Haddocks have been clarified, especially for budgetRollup. In some
ways things are much clearer without this feature, but it remains
enabled by default for now.
Budgets were restricted to a single interval in 1.9, but this was
a mistake. This restores the 1.5 behaviour, where a budget can be built
up from multiple periodic transactions with different intervals.
