Re: [GSoC] Proposal: Modular LilyPond Parser (C++)

Proposal for Google Summer of Code: Modular LilyPond Parser in C++ [...]

Thanks, Werner, for your quick reply.
Sorry for taking a bit longer — I didn’t want to give a hasty answer.

 > * Would there be any direct benefit for LilyPond per se?

In short: LilyPond itself does not need the AST — but the LilyPond 
project benefits greatly, because the ecosystem (editors, analysis 
tools, or alternative implementations) becomes more modern, modular, and 
sustainable.

 > * How do you ensure that your parser stays in sync with the one  
LilyPond uses?

The classic problem of double maintenance or parser drift cannot be 
fully avoided with an external parser. I follow the official syntax, 
test against real LilyPond files (e.g., the version‑parsing example 
shown in my video), and keep an eye on syntax changes in new releases, 
such as the simplified \break behavior in the middle of a measure. In 
the long run, I also plan to study changes in parser.yy to detect 
relevant developments early.

For editor tools, I also consider a certain degree of error tolerance 
important, so that incomplete or malformed LilyPond code can still be 
opened. In my previous voice parser, for example, cis128' was 
interpreted as cis'128 and automatically corrected after clicking on the 
graphical representation — something I find very convenient as a user. 
At the same time, too much tolerance can lead to misinterpretations in 
ambiguous situations. As a compromise, I plan to make such repair 
mechanisms optional (e.g., via a “repair flag”). I would be happy to 
discuss where such tolerance is helpful, and where it begins to blur the 
intended semantics.

 > * There is a nice, new Emacs mode for LilyPond available at [...] 
Have you seen it?
I know the Python parser mostly from a user perspective, since I have 
been using Frescobaldi for a long time. Thanks also for the hint about 
the new Emacs tree‑sitter integration — I haven’t looked at it yet, but 
I’d like to explore it as an additional reference.

Best regards,
Christian