The lexer reads regular expressions, and tries to match them to a rule.
A rule will return a token and a value (yylval). These two will be used
by the parser to interpret the input.
This is so simple.
So for example how a note name is recognized:
a note name like fs will be read as [a-zA-Z\200-\377]+ regular
expression (ALPHAWORD in lexer.ll).
In notes and figure lexer state (<notes, figures> in lexer.ll) it will
return scan_bare_word, based on the rule:
<notes,figures>{
{ALPHAWORD} {
return scan_bare_word (YYText ());
}
scan_bare_word is a function that takes the matched input and return the
appropriate token and set the appropriate value in yylval. Look at the
implementation of this function to understand how that token is actually
generated.
Bert
Harmath Dénes wrote:
On 2010.03.04., at 19:36, Patrick McCarty wrote:
2010/3/4 Harmath Dénes <harmathde...@gmail.com>:
Greetings all,
it's great to have a grammar of LilyPond in the NR! But there are terminal
rules which are not strings (BOOK_IDENTIFIER, CHORD_MODIFIER etc.). Where can
their definitions be learned?
If you do a `git grep' for them in the source tree, you will see that
many of these terminals come to life in the lexing stage.
I see. The -p option gives even more useful output.
For example, BOOK_IDENTIFIER is the return value of
Lily_lexer::try_special_identifiers() in lily/parser.yy, but only if
its second argument is a Book smob.
-Patrick
It's not exactly clear to me how lexing and parsing are related, since there
are lexer rules (e.g. NOTENAME_PITCH) which can be set from Scheme code. Could
someone shed a light on this?
Thanks,
thSoft
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel