[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.