John Walsh writes: | On the subject of bangs and stars for linebreaks and | decorations...I haven't been following it closely, and now I admit to | being a bit puzzled as to the status of what's being decided. It | seems to me that using ! for both a hard linebreak and for ! ... ! in the | same tune is asking for trouble. Using spaces to help distinguish them | (did I see that suggested?) will lead to really frustrated users who can't | understand why abc refuses to behave as they expect
What seems to have happened is that I and a few others pointed out that we don't really have a serious problem with the two uses of ! right now, because a simple heuristic can tell which meaning was used in a tune. But some people misinterpreted this to mean that both could be legal in the standard language. But using both in a single tune is a parsing disaster. This sort of situation arises in software standardization efforts all the time. Vendors X, Y and Z implement the standard, with their own favorite extensions. Each extension is fine on its own, and it's not difficult for software to distinguish them (especially if there's some sort of id to test). But they can't all be implemented in the same software for some reason. In such cases, it's normal for X, Y and Z (and their customers) to dig in their heels and insist that the standard follow their lead. The standard committee (or voting population) eventually has to just shrug and make a decision. That decision might be to not add any of the extensions to the standard. More often, a scheme is worked out that forces one or more of the vendors to revise their software if they want to be able to claim standard compliant. In our case, one use of ! was implemented, but nobody except the users of one tool was aware of it. Even after I noticed the funny ! char in some tunes, it took me a couple of years to discover what it meant, since the tunes made sense if I just ignored it. Then another (very public) discussion of annotaions started, and the suggestion came up to use ! as a quote char, because it wasn't being used in abc yet. As far as most of us knew, it was unused, and was available. So several other important abc tools started recognizing the !...! construct, and it became a de-facto extension to the language. We could change all those programs to use a different delimiter, and edit all the abc that uses !...! to use the new delimiter. Or we can ignore the conflict, and make !...! the standard. This wouldn't actually be all that bad an idea, because the simple heuristic still works. The one thing that really won't work is permitting both in one tune. It's likely that abc2win won't be changed to match any new standard, as it wasn't changed to match the 1.6 "standard". But this doesn't make that much difference, as we'll just need some bits of code to spot the abc2win ! and ignore it. And if Jim decides to update abc2win, or passes the code to someone else, we can strongly suggest that it be updated to the standard. My feeling is that the active developers shouldn't be held back by a popular but obsolete program that isn't being maintained. This is a "slippery slope", as the media calls it, and will just invite more such problems in the future. The practical approach is to add the !...! notation to the standard, accept that there are old programs that aren't compatible with this and other minor points, and note that there's a simple workaround in this case. For that matter, we have lots of other "standard" features of abc that aren't implemented by some programs. And cases like continuation that are done differently by different programs. It's not that big a deal. We can just decide what the standard should be, and use social pressure to try to get programs up to date. Or not. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
