Another Beancount parser in Rust

[tesujimath]

Hey there! 👋

I'm just reaching out with a bit of an apology. I just published my own beancount-parser crate. It was only when I failed to publish it under its original name that I discovered the existence of yours. Yeah, that's a bit negligent on my part not to check before even starting I know. I'm sorry this happened!

Next week I'll probably make some announcements as to the existence of mine. I didn't want you to see those and get a bit annoyed with the situation, hence this message.

My main focus was growing my Rust experience, for which it has been the ideal project.

Notwithstanding the mistake I made here, I quite like where mine has landed, and intend to continue by adding Python bindings (unless that turns out to be a huge bother).

I haven't greatly explored your parser. At first glance, I think mine has more sophisticated error reporting. I'm unsure as to your completeness of coverage of the Beancount file format. Mine is pretty complete as far as I am aware (except plugins and query and custom directives.)

Anyway, sorry for the duplicated effort.

cheers,
Simon

[jcornaz]

Hi,

Thank you for the message, that's very kind of you.

You don't need to worry. I think that multiple people implementing and publishing different solutions to the same problem is a good thing. I wish you success with your project.

"duplicated effort" is not a bad thing in my opinion but a good thing. People should reinvent the wheel more often, almost all products I like (including rust and beancount) are reinventions of things that already pre-existed. I am happy that you wrote a beancount parser. It means I'll be able to look at it, get ideas from it, better understand how to improve mine, etc.

And thanks to you, I am now aware of the existence of logos and chumsky, which are both looking quite cool :-)

Notwithstanding the mistake I made here, I quite like where mine has landed, and intend to continue by adding Python bindings (unless that turns out to be a huge bother).

I don't think it is a mistake. And it's nice that you like what you've done, you can be proud of it. You should continue to work on it for as long as you enjoy working on it. Don't let the existence of a similar project spoil your fun ;-)

I have no interest in Python personally, but I hope you'll have fun with that :-p

At first glance, I think mine has more sophisticated error reporting.

Yes, definitely. The error reporting is the biggest weakness of my implementation and I would like to improve it (#41). But I have no idea if I'll ever actually do it.

Mine is pretty complete as far as I am aware (except plugins and query and custom directives.)

Mine should be pretty complete too. There are some limitations for the metadata value types, but it would take me a few minutes to complete that support if someone asked for it.

I wish you all the best with your project.

[tesujimath]

Thanks for your gracious reply, Jonathan. All the best!

[blais]

Do you guys think we should have an official Beancount parser in the official repo?

…

On Fri, Nov 10, 2023 at 2:18 PM Simon Guest ***@***.***> wrote: Thanks for your gracious reply, Jonathan. All the best! — Reply to this email directly, view it on GitHub <#56 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACSBE4QVEIBGE2ZLNMTDP3YDZ4WTAVCNFSM6AAAAAA7FTKRTOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMZWG43TE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[tesujimath]

Hi Martin,

I would suggest not. Jonathan already pointed out the value of having multiple implementations, and I do agree.

What would make any one of these official, except being used by the main Beancount program itself?

No third party parser is yet ready for use by Beancount proper (although I am wanting to take that direction for mine!)

What I think would certainly be of value would be to have some kind of test suite, so multiple parser implementations could test their mettle. Probably initially this would comprise a collection of Beancount files with complete coverage of the language and all its edge cases.

cheers,
Simon

[jcornaz]

I agree with Simon, unless beancount itself is using it and involved in its maintenance, then there is no "official" parser.

You may however mention the existence of both parsers and let people decide for themselves. If you have a personal favorite, you can also say so. I would just not call them "official".

What I think would certainly be of value would be to have some kind of test suite, so multiple parser implementations could test their mettle. Probably initially this would comprise a collection of Beancount files with complete coverage of the language and all its edge cases.

Yes, fully agree. An official test suit would be awesome! Even if it's just a collection of files that the parser should successfully parse and maybe another collection of files that the parser should recognize as containing errors, that would already be great!

[blais]

Adding these links from https://groups.google.com/d/msgid/beancount/CAK21%2BhOciLhn-b%2BjBTxdp622BnWhyEtTjLQYRo6Adj5bzZvNkA%40mail.gmail.com?utm_medium=email&utm_source=footer for reference. These are the current test suites: https://github.com/beancount/beancount/blob/master/beancount/cparser/parser_test.cc https://github.com/beancount/beancount/blob/master/beancount/parser/parser_test.py

…

On Mon, Nov 13, 2023 at 5:17 AM Jonathan Cornaz ***@***.***> wrote: I agree with Simon, unless beancount itself is using it and involved in its maintenance, then there is no "official" parser. You may however mention the existence of both parsers and let people decide for themselves. If you have a personal favorite, you can also say so. I would just not call them "official". What I think would certainly be of value would be to have some kind of test suite, so multiple parser implementations could test their mettle. Probably initially this would comprise a collection of Beancount files with complete coverage of the language and all its edge cases. Yes, fully agree. An official test suit would be awesome! Even if it's just a collection of files that the parser should successfully parse and maybe another collection of files that the parser should recognize as containing errors, that would already be great! — Reply to this email directly, view it on GitHub <#56 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACSBE4PK72P3ZPYOKER4RTYEHXTVAVCNFSM6AAAAAA7FTKRTOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNJSGMYDC> . You are receiving this because you commented.Message ID: ***@***.***>