On 06/07/2020 03:00, Stefano Zacchiroli wrote: > You mention you're gonna keep using flex/bison, which is for sure well > known technology. However, the expressivity of bison grammars make it > kinda hard to hack on existing parsers, raising the barrier for > contributors. Have you considered switching to PEG parsing?
I toyed with the idea of writing a PEG parser for Beancount syntax, but I haven't found a nice PEG parser generator. The Beancount syntax is also fairly regular, thus the Bison grammar is actually not that bad to read. Also, there is the desire to keep the v2 and v3 parser definitions as close as possible. > The rework of includes sounds great. We have discussed it on the list in > the past, so I guess it's your goal, but as it's not explicitly stated > in the design doc let me repeat it here. I think the goal should be > "include invariance", i.e., one should always be able to take an > existing Beancount ledger in a single file and break it down in an > arbitrary amount of smaller ledger files that include each other, > without any semantic change. (The stated goal in your doc of being able > to declare plugins elsewhere than in the main file will derive from > this, but this principle is more general.) I have done some work on the parser and I would like to lift the current limits on included also for v2. Once the parser rework lands, it should fairly be straightforward. > The main feature I lack to have feature parity with Ledger-CLI is the > ability to add tags to individual transaction legs. I'm assuming this > will go hand-in-hand with relaxing the distinction between metadata/ > tags/ links (by making them syntactic sugar for metadata, I'm guessing), > which is great, thanks! This is on the to do list. > In > particular, I'd like to know if the raw/syntactic directives you imagine > coming out of the new Beancount core would be close enough to the book > concrete syntax to allow manipulation such as meddling with spacing > Provided that, and a good pretty printer for concrete syntax, a > "bean-sed" project with a dedicated manipulation language can probably > be created and maintained separately of core. I am far from being a parsing expert, but I think having the parser emit a syntax tree suitable to reconstruct the input file without modifications is going to be very complex: the scanner would need to emit many more tokens for input that is now simply ignored (ie trailing whitespace) and the grammar would need to handle those, making it more complex. The representation of the parsing results would also be more complex. A lot of work to support a single tool. I think that a tool like the one you describe should use the syntax tree and the actual file content in combination to rewrite the input file: the syntax tree allows to identify which elements need to be modified and from these the position in the input files where text changes need to happen. Sounds complex, but I believe less complex than augmenting the parser. > Bazel is indeed a great build system, but you should know that, at least > for now, it is not in Debian/Ubuntu yet. So for the time being it will > be impossible to ship Beancount v3 on those distros (and any other > Debian-based distro) until Bazel itself is part of Debian. Work is > ongoing (see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654 > ), but I'm unable to guess when it will actually happen. I had a similar reaction to Bazel. My secret plan is to maintain a parallel build system based on Meson. I did a quick reality check and it seems that all prerequisites can be build with Meson. I think Meson is more non-developer and distribution friendly than Bazel. Cheers, Dan -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/e95f9907-5c8e-960e-cf00-ad7a31cc58b4%40grinta.net.
