I summarized ideas about balance assertions and make a proposal for extensions here: https://docs.google.com/document/d/1vyemZFox47IZjuBrT2RjhSHZyTgloYOUeJb73RxMRD0/
Open for commenting in the margins. Your thoughts are welcome. Thanks, On Thu, Jul 3, 2014 at 3:07 PM, Martin Blais <[email protected]> wrote: > 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.
