Hlöðver Sigurðsson <hlo...@gmail.com> writes: > Yes, that's why I wanted to experiment with boycutting the .ly->scheme-ast > transformation step. I'm a much better lisper than c, so it's bit unclear > to me what's going on (i've done parsers tough in the past). Are these > public functions here maybe what I'm after > https://github.com/lilypond/lilypond/blob/master/lily/include/lily-guile.hh#L52-L53 > because, only by (maybe false) assumption, the lilypond lexer and parser's > job is to create the scheme ast in the pipeline that gets sent to another > compilation step which job is to create raw typesetted output?
I repeat: > 2017-07-20 16:57 GMT+02:00 David Kastrup <d...@gnu.org>: >> >> LilyPond is an interpreter, not a compiler, so it doesn't work with >> parse trees. See lily/parser.yy for its parser (and associated actions) >> and lily/lexer.ll for its lexer. There is no "scheme ast". LilyPond executes its actions as soon as it recognizes a production. Those actions ultimately assemble "book" expressions which are then processed with functions/hooks like toplevel-book-handler . The basic control flow outside of the parser is done in ly/init.ly . -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
