Remo D. wrote: > Hi there. I've prepared a proof of concept. It's only a scanner for ABC > files but already features Lua handlers (as well as C handlers).
My biggest concern is that ABC (especially when you try to support older *and* newer versions, which is really necessary given how much stuff is out there) has enough special cases, state dependencies, and other oddities in it's parsing that I think your scanner will probably need a whole lot of context to work with. Certainly the handlers will need to have that context, and if you keep all context out of the scanner, the handlers will need a LOT of context. For that matter, I don't think your handler processing is going to work as it stands unless each handler contains a bit of code for each possible state a token could appear in -- which could make them huge, difficult to manage, and very difficult to extend. For example, take the token "C". Well, that could be a note, or it could be a key name, or a syllable in a lyric line, or a clef name, or a chord name, or a meter, or part of a title, area, book, composer, discography, or who knows what else. In a simple scanner as you're suggesting here, which doesn't look at the context, in most cases you're likely to have that come back as a T_NOTE token. Then in the handler for T_NOTE, it's going to have to figure out from the context what on earth it's going to do with this "C" token -- a fairly complicated task. The task becomes easier if you switch to a callback mechanism to obtain the next token (and one to push it back on the token list if you decide not to use it), and recursively pick your handler based on the current context. For example, the handleMeterToken handler would itself call abcNextToken() to read in the next token, and have it's own list of handlers for those tokens which might be relevant within that M: field. So the "C" token there would be processed by the handleTNoteInMeterField handler instead of something more generic. As far as using Lua for the handlers, I'm not certain what advantage that gains you if any, especially given how much context you'll need to be passing back and forth to the handlers, and the need to call back into C to get the next token. (Is that even possible in Lua?) I suspect the overhead of calling between Lua and C will slow the parser speed down considerably as well. If you're going to use Lua at all, I'd think you'd be better off writing the whole thing in Lua instead, leaving only a single C entry point to feed in a file and get back a data structure. Or better yet, forget the Lua handlers and write the whole thing in pure C. Lua isn't very well known (I first heard about it here...), and an application writer is more likely to pick code in a language he knows than one he doesn't. Paul Rosen wrote: > I'd define success as one or both of the following: > > 1) Everyone who is supporting ABC programs likes it and switches to this > parser so that every program will interpret files the same, now and forever. I'd undefine this one. I don't believe it will ever happen, simply because I don't think it is possible to define a single ABC parser capable of serving the needs of all applications out there. You can make one which will serve most of the needs of most of the applications, but it's never going to be perfect. Instead, I'd define a "success" goal of having a parser that is sufficiently easy to understand and well documented enough that someone who needs to either modify or extend it can easily do so, and that someone who needs write a new parser can use it as a reference. Paul Rosen also wrote: > I don't agree with your statement "To keep things simple I won't use C++ > with all his many unnecessary complications." What complications are you > thinking about? The advantages of object oriented programming are so strong > it seems silly to arbitrarily limit the development team. Can you even get a > C compiler anymore that doesn't support C++? It is simple to avoid name > mangling and v-tables in the API, if that is what you are afraid of. I think the biggest limitation of C++ is it's suitability as a linkable library. I've had trouble linking a C++ containing library with a pure C application (much less any other language), because the C application doesn't have the C++ run time initialization code. You can get around that problem in a variety of ways, but they're mostly compiler and platform specific and not very portable. Once you start working your way around the compiler issues and portability issues, you've basically recreated COM (or some similar object model) from scratch. That said, if you know of a portable way to have C++ embedded in a library that is linkable into applications in a portable, compiler independent way, I'd say it could work for a decent amount of the internals. I would prefer Objective-C (it's really ideal for this kind of work), but as I pointed out above with Lua, it's not as well known. (Except in the Mac world...) -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
