[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Denemo-devel] LilyPond parsing
From: |
Richard Shann |
Subject: |
[Denemo-devel] LilyPond parsing |
Date: |
Sun, 08 Aug 2010 18:26:59 +0100 |
Here are some notes (mainly for my own benefit)
Although there is a mid-rule action for SCORE '{' ... this is only
inside markup. Mid-rule actions can always be replaced by extra rules
anyway - see
http://www.gnu.org/software/bison/manual/bison.html#Mid_002dRule-Actions
for details
Our denemo lilypond parser pushes the notes state at the outset before
starting the lexer - the LilyPond lexer creation routine appears to do
the same (see push_note_state (scm_c_make_hash_table (0)); in
lily-lexer.cc in the
Lily_lexer::Lily_lexer (Sources *sources) {...} function
However, as far as I can see, it does not properly come out of that
state when parsing assignments - they may only work because they don't
happen to start with chars a-g and so are not recognized as note names!
It was not obvious to me why LilyPond would not still be in <notes>
state when it came to an assignment - the rules are stateless, like this
assignment:
assignment_id '=' identifier_init
...
assignment_id:
STRING
The explanation is that the rules for recognizing an ALPHAWORD in notes
state come first. You cannot have an assignment inside music - if the
name of the assignment_id something like MvmntI... then it says that is
an unexpected STRING, if you try to make an assignment using a name
that *is* also a note name inside music it does not trigger that error,
because it will not lex as a STRING but instead as a NOTENAME_PITCH.
On further investigation, the LilyPond lexer is actually slightly cruder
- you cannot use a notename as an identifier
so
a = { c dis e}
is actually not valid even where other names than a would be, that is it
is not valid outside a scoreblock where
myname ={ a b c} would be
Richard
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Denemo-devel] LilyPond parsing,
Richard Shann <=