Awhile ago there was a lot of discussion about a general-purpose parser for ABC. I created one some time ago, it is part of my program iabc. Info is at the usual place, http://abc.sourceforge.net/iabc Included in the program is a unit test program that is a stand-alone parser (called utparse). As all it does is parse abc and print some things out about the structure of what its reading in. It is in C++ and it converts the music to a pretty intuitive format with classes for pitches, notes, and 'music info' things like repeats, codas, etc. If you don't want that, you can override the 'convert' methods of the rules to convert the parseable units into your own constructs. This is in the file abcrules.cpp. I was too busy when this thread was going on, but I don't know that you will find this as useful as you might think. In order to get a parser to be at all efficient, you have to do some optimizing which seems to detract from the intutiveness of the BNF-form grammar. For instance, you have to do some 'common sense' look-ahead to determine if 'C' is a part of the copyright header or the note 'C', or else you end up iterating through a lot of rules on every character that you encounter. But, I tried to use C++ as well as I could to maintain a BNF-ish feel. For instance, the code for the meter-specifier (M:) rule uses 'and' and 'or' in the expected way to combine other rules (see example). The terminal rules are based on regular expressions, and the parser contains a fairly efficient regular-expression implementation. non_terminal meter_specifier_rule::create_complete_rule() { return ((my_header & my_whitespace & my_numerator & my_slash & my_denominator) | (my_header & (my_cut | my_other_cut | my_common))); }
<<winmail.dat>>
