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
