>>>>> Simon Michael <[email protected]> writes: > But note they can't choose (in Ledger) to place dated assertions at one end > of the journal, or in a separate file - because Ledger's assertions > currently follow *only* parse order, ignoring of the date of the posting > they're on. I had forgotten this. It sounds like John would change this but > it's awkward with the current implementation, because it processes > assertions during parsing.
Yes, I've dumped at least a day into this problem, but Ledger's current processing pipeline won't allow it without back-tracking or caching huge amounts of data in memory, or recalculating certain figures from scratch each time they are needed. I'm convinced Ledger should have adopted an intermediary data representation: Parse data into "raw" structures, and then "cooking" these structures. At the moment it parses directly into the cooked form. Having an intermediate "raw" representation would allow me to do many things much more easily, order-independence being among them (or so I believe). My Haskell version of the Ledger parser does exactly this, but changing the C++ code would be a huge refactoring, and beyond the scope of what I want to do to that code right now. If I were to spend large amounts of time doing new development, it would be in Haskell with a hope to merge efforts with Simon toward more feature parity for hledger. I'm quite happy with C++ ledger's current feature set and stability, so my goal there is to keep that purring along, modulo fixing important problems like rounding and currency evaluation. John -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
