My parser is a little more generous. I got fed up with having to correct
files that others had created. If you can't beat them, join them. I allow
T: without X:
L.
----- Original Message -----
From: Wil Macaulay <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 06, 2002 5:15 PM
Subject: Re: [abcusers] The X: field
depends whether you consider a tune as including free text before or
after it. My parser starts in a lexical state that ignores all lines
up until the first line that starts with X: (could do the same for T:
but I dont) and then switches to a state where it parses the tune
header. It stays in that state until parsing a K: line, then a different
lexical state for parsing the tune body. Back to initial state after
a blank line.
That way I just ignore extraneous text between or before tunes.
You need to make a decision early (i.e. right now) as to the scope of
your project - do you want to be able to do useful things with the
bulk of existing abc on the net, which may be full of comments
and ropey abc, or do you want to pick a well constrained subset
of abc (for example, one tune per file, strict 1.6 standard) and
use that to build your program. I started by defining my requirements
as being able to display Henrik Norbeck's collection, and added to
it as I went. I would suggest, given your time constraints, that you
take the second approach, and decide when you've finished that
which way to go.
wil
Christian Cepel wrote:
> On Wed, 6 Mar 2002, John Chambers wrote:
> > This is in line with current practice, and isn't really much of a
> > programming problem. It makes recognizing the start of a tune a bit
> > more involved. The code has to accept either X: or T: as starting an
> > ABC tune, and default the index to 1 if no X: line was seen. This is
> > a bit more complex than just matching "X:", but it's not what you'd
> > call an onerous burden on any programmer.
>
> Granted, I haven't written our parser yet, but this makes no sense to me.
>
> If the tune delineator is one or more blank lines in a tune, it would be
> NUTS to assume that a tune starts with either an X: or a T: is the start
> of a tune. What's to assume that tune writers are going to follow this
> 'rule' more than any other.
>
> Maybe I'm nuts, but I was invisioning my parser looking for the first
> alpha character in the file as the first tune, and then for the first
> alpha character after groups of more than one EOL marker. Seem's
> completely straightforward and easy, and in no way dependant or easier or
> harder than if an X: line is included. (I've not mentioned the one
> exception I can think of, which is the % token.
>
> Maybe I've misread the standard. What I can't figure out is
> a) is this true and I don't understand it?
> b) am I right and you don't understand it?
> c) am I right and for some reason people are motivated to deliberately
> mislead and confound the issue.
>
> I'm perfectly willing to admit that it might be a) .. in fact I'd rather
> it be a) because it means that someone will probably explain why I'm
> mistaken, and I'll write a better parser w/o having to rewrite out
> mistakes. I certainly don't place emphasis on c)
>
> --
> + Christian Marcus Cepel ("`-''-/").___..--''"`-._ +
> | [EMAIL PROTECTED] `6_ 6 ) `-. ( ).`-.__.`) |
> | 5812 Square Circle, Columbia 65203 (_Y_.)' ._ ) `._ `. ``-..-' |
> | Work: 882.8309 Home: 573.443.8676 _..`--'_..-_/ /--'_.' ,' |
> | ICQ: 12384980 Cell/Page 268.7533 (il),-'' (li),' ((!.-' |
> | Computer Support Specialist, Sr. School of Info Sci & Learn Tech UM-C |
> | WebM: www.coe.missouri.edu/~vrcbd/ *And the wrens have returned & are |
> | nesting *In the hollow of that oak where his heart once had been *And |
> + he lifts his arms in a blessing *For being born again. --Rich Mullins +
>
> To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
