[GSoC] Proposal: Modular LilyPond Parser (C++)
"C. Stroppel" <[email protected]> Thu, 12 Mar 2026 00:37:04 +0100
| Newsgroups | gmane.comp.gnu.lilypond.devel |
|---|---|
| Message-ID | <[email protected]> |
Please excuse my delayed response; however, the stronger the arguments I
am addressing, the more time I require to reflect on them. First of all,
I would like to express my gratitude for the development of LilyPond,
which I have enjoyed using for many years.
> parser.yy and lexer.ll are machine readable descriptions of the
syntax, so IMO, they are superior to EBNF or a YAML based grammar.
I must concede that lexer.ll and parser.yy are machine-readable to the
extent that I have since been able to write a experimental program to
extract some relevant data. Perhaps my concern was more about
human-readability—one of the primary reasons I originally chose
LilyPond. I feel this is partly being lost the more Scheme is utilized.
While extracting tokens from lexer.ll and parser.yy, I noticed for the
first time that many music functions, such as \clef, exist in Scheme but
are not recognized by the lexer. This raised the question for me whether
it would be sensible to recognize established music functions earlier in
the lexer.
Three arguments support doing it this way in my lexer:
1. Relieving the parser so that it no longer has to resolve
ambiguities.
2. Stabilizing the syntax by recognizing more literals in the
lexer. - Guaranteed stability of literals and syntax was the second
reason LilyPond became attractive to me.
Too often, I was unable to open old compositions with new
software.
3. I want to be able to use the fast lexer for syntax highlighting
without the parser, reserving the parser solely for rendering.
I will describe the planned architecture in more detail in the coming days.
Best regards,
C.