Hi there!
Thanks for your replays. I try to summarize the points so far (at least my
conclusions), please correct me if I'm wrong.
1) To increase portability we should stick to plain ANSI C. I'm perfectly
fine with it. The "complications" I was referring to, Paul, were those that
you encounter when you try to access a C++ library from another language
(including C).
2) My proposal of using Lua seems to be misleading. Let us put it in a
corner for a while we could come back on it at a later stage of development.
Tom Satter already offered to write python handlers, which is good for me.
This implies that the parser will be a library in ANSI C and that there
will exist bindings for different scripting languages. This is a very common
situation but requires some planning ahead.
3) The library will keep the state internally. Steven Bennet gave an
example about "C". In the present stage the scanner will return T_NOTE or
T_CHORD together with the "C" string depending on the context, we need to
extend this behaviour to the whole parser. In cases like "K:none" or "K:"
the parser will not give any error, the callback will be called with
something like P_FIELD_K and an empty string. It will be up to the handler
to decide if reject it or not.
4) The parser will endorse ONE syntax and will try to accomodate for as
many extensions as we can. I can see it's not easy, we have to come up with
a solution! Any suggestion?
5) Tom Satter rightly pointed out that we have to choices: having callback
that gets called each time an element is found or creating the entire
structure and offering an API for navigating into it. I do esitate to do the
latter because I've heard of ABC files with thousands of songs in it! I
would like to be able ot handle them without requiring megs and megs of
memory.
The idea in the proposal (please tell me if some point need clarification,
consider that english is not my first language) tries to accomodate this
situation. It will offer a call back mechanism and a set of default handlers
that builds an internal rapresentation of the ABC file.
It's not clear to me if you support this approach or not!
6) As Paul Rosen suggested I had a look at MusicXML. I found it very
complicated for my taste but I'm not able to judge if all those details are
necessary or not. For example, is it necessary to be able to traverse the
score both by parts and by measures? I'm not sure I understand, my music
background is too limited I think!
Has anyone a suggestion on how the ABC file should be represented?
7) I also do agree with Paul not to use commercial parsers, that's why I
used re2c for the lexer. My candidate for the parser is lemon, as always I'm
open to suggestion.
8) Next proof of concept will feature the parser with callbacks. I'll try
to include as much as ABC2.0 draft syntax I can.
In the meantime, please comment and give me suggestions. As Christian
said, I could fall short of enthusiasm! :)
Bye,
R.D
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
