I don't see any desire to reconcile the syntaxes between the projects. They're different enough that this would require a lot of changes. Also, the interpretation of that syntax would have to be reconciled and that's even more of a stretch. Furthermore, it would make it more difficult to change the syntax in the future. I see what you mean, in theory that could have been nice, but those things evolved separately.
In the future I'd like to splice off the core, parser, booking and plugins code to a smaller project that would spit out the booked transactions to protocol buffer objects. The stream of protocol buffer objects could then be queried by the SQL tool (also splice off, to its own project). In theory the other projects could implement a backend to the same schema and leverage the query tool. Just a thought. On Sun, Apr 21, 2019 at 3:41 PM Alen Šiljak <[email protected]> wrote: > This has been mentioned elsewhere but I'd like to open an explicit topic > about compatibility between (H)Ledger and Beancount. > From what I understand, Beancount syntax started from Ledger but went its > own way (as is to be expected with any two projects, people, plants) over > time. > On the other hand, ledger's syntax also evolved to include some > functionality, which also makes sense. > > Now, the question is - why can't they both use the same syntax? Or a > subset of syntax. > Here I would argue that the data file is just that - data. There are > tendencies to make it more code-like and include instructions, macros, and > other executable type of stuff. I would be prefer to keep data static and > add things like tags, if the existing record properties are not enough, > upon which executable code could make decisions. I know this sounds > simplistic but that's the general idea. > > The end result, I'd be delighted to see, would be > > - modular application, which is something Martin is doing with BeanCount, > with pluggable components; and > - compatible (subset of) data syntax > > Any incompatible syntax should simply be ignored (i.e. virtual accounts > and that sort of things). In that case, having different applications use > the same data set, they could provide different but complementary > functionality. For example, I'm excited about the way Asset Allocation can > be implemented with Ledger using virtual accounts and automatic > transactions. This is something I can extract into a separate file and only > run when I want to see my current asset allocation. > It also provides a modular data structure, where multiple files can be > combined into the end results. I have already separated my data into > accounts, commodities, journal, prices, and asset allocation definition. > Seems to work great with Ledger. I wonder how useful this structure will be > with Beancount, considering it requires Open Account directives. > Anyways, food for thought and discussion. > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/84361346-3fdc-441f-8c19-2529da547484%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/84361346-3fdc-441f-8c19-2529da547484%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPEoj5%2Bb4KBMPVjEhx8ZJcseY4qqJFNDtr4gSB2dYDqDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
