On Mon, Jul 6, 2020 at 6:18 PM Daniele Nicolodi <dani...@grinta.net> wrote:
> 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. > Seems doable. I mean, frankly just getting errors for unsupported syntax in included files goes a very long way here. > > 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. > +1 We'll just have to figure out how to do this the same way for postings and transactions. It wouldn't be super nice if they are stored one way on transactions and a different way on postings. That's why I was thinking we could rework the way transactions store tags and links first, and then do that. > 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. > +1 Not worth it IMO, too much work. > > > 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 i> > 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. > Do you drink Pepsi? ;-) > 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 > . > -- 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/CAK21%2BhOOQDm2i%2BaBvKbuCK-CNr1ZwaQ_nmu1V%3Dt97Z7Sa5Xt2Q%40mail.gmail.com.
