Re: [abcusers] Re: ABC 1.x continuations
On Fri, 12 Mar 2004, Steven Bennett wrote: So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. Steve, I think you've made a thorough and clarifying analysis of the actual 1.* backslash semantics. Now I understand and appreciate what you've been trying to say. I think your restatement of the 1.* backslash rule is brilliant! I will add a note about it to the backward compatibility section of the ABC 2.0 draft. Thank you for this\ contribution. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* ABC Standard: http://abc.sourceforge.net/standard/ Chazzanut Online: http://www.chazzanut.com/ Synagogue Choir: http://www.ask-choir.org/ Business: http://www.amsterdamhotelspecials.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
On Sun, 14 Mar 2004, Phil Taylor wrote: It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. In ABC 2.0, continuations and ordinary comments will typically be dealt with by the scanner, before the parser even sees them. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* ABC Standard: http://abc.sourceforge.net/standard/ Chazzanut Online: http://www.chazzanut.com/ Synagogue Choir: http://www.ask-choir.org/ Business: http://www.amsterdamhotelspecials.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
On 16 Mar 2004, at 14:52, I. Oppenheim wrote: On Sun, 14 Mar 2004, Phil Taylor wrote: It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. In ABC 2.0, continuations and ordinary comments will typically be dealt with by the scanner, before the parser even sees them. Yes but this was the example: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| after dealing with the continued line you get this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:M:3/4 G]def|gab| Whether you choose to handle this in the parser or in a preprocessor, the result still aint legal abc. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] Re: ABC 1.x continuations
just my 2p As I understand, this example should not be legal for 2.0 so getting an illegal result is correct. If it is the 1.x idea of 'continuation of the same type of line' then it seems unclear (unless using Steven's interpretation) whether it should be legal. If the parser should 'not have to deal with it' then it would be best if the standard disallowed the construction. Certainly, nobody typing ABC direcly would be likely to do this , but I can see that this kind of thing could arise when writing a rouinte to generate ABC from some other format, or a routine to prettify the printed ABC by readjusting the line breaks, etc. 'anything not prohibited is allowed' (at least computers see it that way) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Taylor Sent: 16 March 2004 17:03 To: [EMAIL PROTECTED] Subject: Re: [abcusers] Re: ABC 1.x continuations On 16 Mar 2004, at 14:52, I. Oppenheim wrote: On Sun, 14 Mar 2004, Phil Taylor wrote: It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. In ABC 2.0, continuations and ordinary comments will typically be dealt with by the scanner, before the parser even sees them. Yes but this was the example: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| after dealing with the continued line you get this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:M:3/4 G]def|gab| Whether you choose to handle this in the parser or in a preprocessor, the result still aint legal abc. Phil Taylor 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
Re: [abcusers] Re: ABC 1.x continuations
It was an outrageous example on purpose. It's *definitely* not legal ABC 2.0, but the definition I was hearing implied that it would be legal ABC 1.*. Which I didn't think it *ought* to be. Which is why I offered my own definition of what the actual 1.* behavior ought to be. That said, the following is perfectly legal in ABC 2.0, by the definition currently in the August draft spec: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ G][M:3/4]def|gab| It's just not legal in ABC 1.*. IMHO. --Steve Bennett On 16 Mar 2004, at 14:52, I. Oppenheim wrote: On Sun, 14 Mar 2004, Phil Taylor wrote: It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. In ABC 2.0, continuations and ordinary comments will typically be dealt with by the scanner, before the parser even sees them. Yes but this was the example: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| after dealing with the continued line you get this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:M:3/4 G]def|gab| Whether you choose to handle this in the parser or in a preprocessor, the result still aint legal abc. Phil Taylor 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
Re: [abcusers] Re: ABC 1.x continuations
Steven Bennett writes: | It was an outrageous example on purpose. It's *definitely* not legal ABC | 2.0, but the definition I was hearing implied that it would be legal ABC | 1.*. Which I didn't think it *ought* to be. Which is why I offered my own | definition of what the actual 1.* behavior ought to be. | | That said, the following is perfectly legal in ABC 2.0, by the definition | currently in the August draft spec: | | X:1 | T:some made up tune | M:4/4 | K:Dminor | abcd|efga|[K:\ | G][M:3/4]def|gab| | | It's just not legal in ABC 1.*. IMHO. Well, I'd agree that it's legal ABC 2.0, but I'd also claim that it should work under the earlier standards. I don't see any reasonable way that a parser would classify the last line as anything other than music, which is the same type as the continued line. It's not a header line, because it doesn't have a ':' in column 2. It doesn't start with '%'. What else could it be except music? I really liked the perverse example with the w: lines that were to be continued on the *second* subsequent w: lines. That one would make just about any programmer run screaming from the room. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
Steven Bennett writes: | It was an outrageous example on purpose. It's *definitely* not legal ABC | 2.0, but the definition I was hearing implied that it would be legal ABC | 1.*. Which I didn't think it *ought* to be. Which is why I offered my own | definition of what the actual 1.* behavior ought to be. | | That said, the following is perfectly legal in ABC 2.0, by the definition | currently in the August draft spec: | | X:1 | T:some made up tune | M:4/4 | K:Dminor | abcd|efga|[K:\ | G][M:3/4]def|gab| | | It's just not legal in ABC 1.*. IMHO. Well, I'd agree that it's legal ABC 2.0, but I'd also claim that it should work under the earlier standards. I don't see any reasonable way that a parser would classify the last line as anything other than music, which is the same type as the continued line. It's not a header line, because it doesn't have a ':' in column 2. It doesn't start with '%'. What else could it be except music? The problem I have with considering that as legal, is that it could just as easily have been written like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[\ K:G][M:3/4]def|gab| If the one is legal in 1.*, the other should be. But this second one is a whole lot more ambiguous for a parser. It's just as well if we avoid the problem by treating *both* as illegal in 1.*, since it's unlikely anyone would actually want to use either form. And by doing so, you drastically simplify the parsing process. (Okay... You drastically simplify *my* parsing process. grin Someone using a different approach might find what you are suggesting easier to deal with...) --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations
On 16 Mar 2004, at 20:50, Steven Bennett wrote: Steven Bennett writes: | It was an outrageous example on purpose. It's *definitely* not legal ABC | 2.0, but the definition I was hearing implied that it would be legal ABC | 1.*. Which I didn't think it *ought* to be. Which is why I offered my own | definition of what the actual 1.* behavior ought to be. | | That said, the following is perfectly legal in ABC 2.0, by the definition | currently in the August draft spec: | | X:1 | T:some made up tune | M:4/4 | K:Dminor | abcd|efga|[K:\ | G][M:3/4]def|gab| | | It's just not legal in ABC 1.*. IMHO. Well, I'd agree that it's legal ABC 2.0, but I'd also claim that it should work under the earlier standards. I don't see any reasonable way that a parser would classify the last line as anything other than music, which is the same type as the continued line. It's not a header line, because it doesn't have a ':' in column 2. It doesn't start with '%'. What else could it be except music? The problem I have with considering that as legal, is that it could just as easily have been written like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[\ K:G][M:3/4]def|gab| If the one is legal in 1.*, the other should be. But this second one is a whole lot more ambiguous for a parser. It's just as well if we avoid the problem by treating *both* as illegal in 1.*, since it's unlikely anyone would actually want to use either form. And by doing so, you drastically simplify the parsing process. (Okay... You drastically simplify *my* parsing process. grin Someone using a different approach might find what you are suggesting easier to deal with...) Certainly if the one is legal then the other should be too. However, I suspect that neither is legal, since inline fields were not legal in 1.x. (Well they weren't legal in 1.6. I didn't pay too much attention to 1.7 since it was such a mess.) I think the tune would have to have been written like this: X:1 T:some made up tune M:4/4 L:1/4 K:Dminor abcd|efga|\ K:G M:3/4 def|gab| (That used to be the main reason for using continuations, so you could place fields in the middle of a line, while still writing the field definition on a line to itself.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- tom satter - or just plain old tom (303) 543-7623 (home) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
Except I'm only proposing this as an aid in defining how to parse 1.* style completions (when the user has selected that as a parsing flag...), not as a change to the 2.0 spec. I actually prefer the 2.0 continuation mechanism, although I'm not strongly attached to it and could see how the 1.* style, defined the way I suggested, could actually make more sense. (Especially, as I think about it, in light of the %%continueall XCommand, which certainly should NOT behave as if one had placed a 2.0 style continuation on each line, but *should* behave, IMHO, as if there was a 1.* style continuation there...) As for the all voices line, I'm not sure I like that idea all that much -- it creates a new parsing state which opens up a number of cans of worms - specifically what is legal when you are in an all voices section and what is not. Possibly a better approach would be using something like [V:*=S] to assign the current voice specific settings of voice S to all other voices. That field would *not* have the side effect of changing voices. (You might also allow [V:A=S] or the like.) So your line below: [V:*] [K:G] [M:3/4] ...might instead read: [V:S] [K:G] [M:3/4] [V:*=S] ...and you would end up being in voice S. I don't know if I like that much either (you still need to define *exactly* which voice specific settings get copied and which do not), but from a parsing point of view, I much prefer it over what you were suggesting. --Steve Bennett I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett 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
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
On 12 Mar 2004, at 23:24, Steven Bennett wrote: I. Oppenheim wrote: As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or Z does, the written spec is awfully vague. I have several possible approaches to different elements of this, but the basic concept appears to be that \ at the end of a line isn't so much a continuation, but a don't break the staff here if you would normally. No. In 1.* it basically meant: continue on the next line of the same type. (Whereas in 2.0 it means: continue on the next physical line, regardless of the context) I don't think I can accept that definition, even though looking at the archives, I've seen that definition before. It implies far too many things which are problematic and not at all true for the programs I have here. Of course, I've only been testing with Barfly 1.52 and abcm2ps 3.7.18 right now. Doubtless other programs behave differently. Problem 1: It implies that you could break a line arbitrarily. For the ABC 2.0 style continuations, that is indeed the case, but we're talking about a 1.* specific parser here, where you can have other lines in-between. So if you allow breaking a line arbitrarily, you could end up with something like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| ...which would need to cache part of the first line (the [K: part) until the next tune data line arrived and it had the remaining info it needed to finish parsing stuff. Even without the meter change in the middle, both Barfly and abcm2ps give parse errors on that. It's a pretty outrageous example. I don't think that parsers should have to deal with continuations in the middle of inline fields, let alone an example with another (non-inline) field inserted in the middle. And it doesn't need a field -- try something like: abcd|efga|c'\ ''def|| ...and you still get errors with both programs, even with nothing inbetween the lines. Doesn't the standard say somewhere that the symbols which form a note cannot be split across line continuations? Even if it doesn't, it ought to. Likewise a lyric line would need to cache partial syllables. Take: X:2 T:another made up tune M:4/4 K:Dminor abcd|efga|bcde|| w:a1 b2 c3 d4 e5 f6 g\ w:7 a8 b9 c10 d11 e12 Now here, Barfly apparently only uses the abc 2.0 style continuations (for lyric lines - odd that it doesn't do the same for tune data lines...), It's supposed to. With the best will in the world I can't always cope with seriously strange interpretations of abc syntax like the above, even if they are technically legal. so it always ends up with gw:7 as a syllable, but ends up with the syllables in the right place. abcm2ps renders this with the g and the 7 as separate syllables, so all the following syllables are off by one note. All of which leads me to conclude that under 1.*, you cannot continue a tune line or a lyric line at any arbitrary character point -- you need to continue it at a point where a staff or lyric line break would be valid. In practice, yes. Problem 2: It doesn't have any inherent limitation on what line of the same type could be. Which means you could continue just about any sort of line. Such as: X:3 T:yet another made up tune M:4/4 K:Dminor abcd|efga|[K:G]\ M:3\ bcde|\ M:/4 def|gab| ...complains about the split Meter line in both Barfly and abcm2ps. (With or without the intervening bcde line...) So it appears to me that it can't work with just any arbitrary field -- IMHO, the only fields it even makes sense to use it on (under 1.*) are tune body lines and lyric lines. And even then it causes all sorts of problems. So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
