On Thu, Jul 3, 2014 at 1:58 PM, John Wiegley <[email protected]> wrote:
> >>>>> 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. > Oh wow... this explains it. Now this makes sense. I was under the impression that balancing was still respecting date order (that's how I implemented it in Beancount). So these are really different kinds of operations: I'll call mine, the order-independent ones that have their own directive, a "balance assertion", and a file-order based ones "running assertions." I don't think I would ever really need running assertions, though IFF all the transactions are present in the input and in sorted order, I see how that makes it possible to support intra-day balance checks. 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). > That's what I do in Beancount. The only "processing" at the parsing stage is ensuring the transactions balance (e.g., filling a missing posting amount). 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. > On a related note about the C++ implementation: What about the booking problem I outlined in this section: https://docs.google.com/document/d/1F8IJ_7fMHZ75XFPocMokLxVZczAhrBRBVN9uMhQFCZ4/edit#heading=h.e2ug3mq1m700 The only way I managed to get an inventory to reduce a position was by specifying both the cost and the date. Is this a bug or intended behavior? If not, is the user expected to always put both the cost and the date in? -- --- 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.
