On Mon, 7 Jul 2003, Bert Van Vreckem wrote: > I. Oppenheim wrote: > > If the ABC community as a whole could provide a > > standard complying parser, not every developer that > > wishes to use ABC would have to reinvent the wheel > > again and again. The current situation is in nobody's > > interest. > > We're already there: using Henrik's BNF spec, a developer can generate a > parser with tools like lex and yacc.
Unfortunately, it is not trivial at all to convert a BNF definition into a working parser. 1/ the parser should be able to ignore future ABC extentions in a graceful way, whatever they may be; 2/ the parser should be able to understand (rather than ignore) non-standard legacy code; 3/ the parser should be able to give detailed error and warning messages (such as: "warning: do not recognize x3/4, in line L, column C", rather than the typical: "syntax error in line L"); 4/ the parser should propagate parser events and data structures to the backend; 5/ the parser should be isolated in a module with a clear and well-defined API; 6/ the parser should never crash! When you use Lex and Yacc, as you suggested, you will come across all kind of non trivial technical problems. Just three examples to give you a taste: 1/ How can Lex know whether a "C" it scans is a note name, or the first letter of a staff label? Maybe it's even the beginning of the composer field! 2/ How can Yacc know whether "||" is one double bar symbol, or two single bar symbols next to each other? 3/ How can Lex/Yacc know whether "E:|" is a (mid-tune) field that starts with a pipe, or a note with a repeat sign next to it? I do not know whether Lex and Yacc are the proper tools to deal with ABC. I think these problems will make clear why it would be VERY useful to create a libabc parser as a group project. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
