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`
