Ledger file compatibility

[Alen Šiljak]

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.

[Martin Blais]

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.

--
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 beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/84361346-3fdc-441f-8c19-2529da547484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alen Šiljak]

On Sunday, 21 April 2019 22:13:09 UTC+2, Martin Blais wrote:

In theory the other projects could implement a backend to the same schema and leverage the query tool. Just a thought.

If the maxim "build it and they will come" is true, it would explain why people are turning to these tools - because they are there and they do the job. With GUIs like Fava and mobile apps, this covers a lot of ground. I mean, I'm also not crazy about having lots of users - that's proving to be quite demanding on support - but having a set of useful tools (and this is where my previous thought comes in) and a group of people maintaining them, is a great goal and destination in itself.

While I understand your arguments, I will continue hoping for the Plain Text Accounting data files to be just that - plain text data files, that I can open, understand, edit, and even add the numbers manually "on paper". The rest of the magic would happen in the apps, or the modules. Well, even if the conversion tools are maintained, that would be good enough.

While I'm not looking to use any crazy syntax with either of the programs, I certainly would appreciate the data files being convertible back and forth, for various reasons.

OK, I put this topic to rest for now.