> To add my two cents to this discussion: While I have my doubts that any
> single parser design could fit the needs of more than maybe half (being
> generous) of the possible applications out there, it's still a worthwhile
> project.
What projects are there? My imagination leads me to the following. I'd love
to know how else ABC could be used.
Standard Notation
Tablature
MIDI Player
Transposer
Indexer
Pattern Matcher
Conversion to another format
Instruction (probably needing fragments)
> I would avoid producing output in any format which needs further text
> parsing, such as a text or XML format. Which leaves a C structure-based
> design a good Least Common Denominator -- most languages can access C
> structures in some fashion.
>
> But the problem with C structures is that they aren't easily extendible,
> which makes it difficult to add features and change things. Another huge
> problem with C structures is that if they contain pointers, those pointers
> become invalid when the structure is moved through memory. (Such as might
> happen on some platforms inter-process communications, or when moved to
> another language.)
>
> However, with proper planning, you can make the returned format highly
> extensible and highly portable by taking a couple of steps early on:
<lots of great ideas snipped>
I've been thinking along the same lines, although I haven't thought as much
about exactly how to express the structures as you have. I'm a little
worried that I'll come up with something that is clever in C++, but is a
pain in other languages.
One idea that I'm leaning towards is having multiple formats to pick from
instead of trying to please everyone. In other words, have a set of
functions like this (I don't like the names, but they are descriptive for
now):
void ParseAbcWithContainers(const string& strAbcFormattedTune,
StlBasedClass& clsOutput, ErrorInfo& clsErrors);
void ParseAbcForFlatStruct(char* szAbcFormattedTune, HandmadeListStruct*
pOutput, ErrorInfo* pErrors);
void ParseAbcToText(char* szAbcFormattedTune, char* szOutput, char*
szErrorInfo);
This is not a big deal. Actually there are two very different issues with
the output format.
1) What data belongs in it, and what is the relationship to other data? For
instance, a rhythm needs to be associated with a note, because if there are
three notes playing at the same time, they could all have different rhythms.
However, a bowing mark needs to be associated with the entire vertical set
of notes. This is a pretty big issue, and is crucial to get right. This has
nothing to do with the physical representation of the data.
2) The physical representation of the data. There are a number of issues,
including extensibility and ease of use in other languages, but in general,
I see this as easier to deal with. There is no reason why we couldn't
support multiple output formats. In fact, I could implement the population
of the data as a templated class, so any C++ programmer could extend it.
Perhaps there is a way to take that idea further and allow programmers of
non-OO languages to create their own formats.
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~catharsis.music/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
