>> Bernard wrote (portions snipped): > I disagree entirely on the "maximise portability". The maximum is ascii. You > can > even read it without a computer. > ... > Sorry, but it seems archaic to me (in a situation such as we are talking > about) not to write the file in ascii.
First off, we're talking about a general purpose parser here, not a file conversion program. In all likelihood, most, if not all, of the programs it will be used with will probably link directly to it, and there will be no intermediate file or storage involved - just a data buffer of some sort returned from a function call. The output isn't intended for an end user - it's intended for a program. The whole idea and purpose of a parser is to put the data in a machine readable format that the rest of the program can actually make use of in a non-sequential fashion. Even with ABC, most of the possible applications out there needs to maintain some information for non-sequential access. A notation program needs to access the key, clef, and time signature as it starts each staff. A player program needs to access the tempo, and will need to loop through repeated notes. Format conversion programs may need to access everything in a completely different order. An editor program might need to randomly access any individual range of notes. And so on. Not to mention that all of them need to access numerical values as actual numbers, not strings. Converting ABC into yet another ASCII based format means that you need to create yet another parser for *that* text format to get it into something your program can actually *use* in a non-sequential format. (And what would the output of *that* parser be, eh?) << My concept of a parser is totally different. It's a standalone program which takes one file and converts to another, more generally usable. It would be called invisibly by any program needing it. That program would then read the simpler file in an obvious form and presumably delete it. Simple and obvious. No need for worries about what language compatibility. There is an enormous gulf between abc format and any structured data list so this is a non-trivial exercise. It would even be able to be licenced for profit to software developers on a per-copy sold basis. The example I quoted above about the OCR routine is an excellent example - the original bitmap contains all the data but the software effort of converting it to musical data is incredible. Similarly abc format to general format is a large task and reading a structured ascii file is surely trivial!! >> You could possibly write that secondary parser to simulate random access - a call to get the key of Tune 15 as of the 23rd measure, for example. But that would be prohibitively expensive in terms of processing time as you reparse the ASCII stuff over and over again. (Yes, even with today's faster processors...) Not to mention the complexity of writing functions to return every conceivable bit of data.<< Of course it's complex! That's the only point in writing the thing in the first place - other people don't want to re-invent the wheel! >> Honestly, it makes absolutely no sense to me whatsoever to be making an intermediate ASCII text format the output of a general purpose parser. It defeats the entire purpose of there *being* a parser in the first place. << I completely disagree. abc to structured music ascii is a huge step. Structured ascii is simple to read. QED. Anyway, you must put your efforts where your convictions are, of course. >> Mind you, I agree that C structures are somewhat archaic, but they do the job. Ideally the output should be a set of objects, but then you'd lose cross-language portability. << I've an open mind on that, since I know almost nothing at this point in time about C structures. Bernard Hill Braeburn Software To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
