James Allwright wrights: | > Laurie Griffiths: | > > Why have these alternatives? They add nothing | > > to the expressiveness of the language. | > | > To me a syntax should allow to write everything that does not harm its | > integrity. | > It is not the target to tell how a text must be written, but how it must | > not be written. | > Any expression a person wants to use should be legal as long as it does | > not collide with the integrity of the syntax. | | In short, why Occam's Razor instead of Occam's entire workshop of shaving | instruments ? I think the answer is that you want people to actually | write programs that will do things with abc. The more encrusted with | options and strange cases a language becomes, the harder it is write | a parser for it and the more likely that the parser will have bugs in | at the end of it all. Also, the harder it becomes to add further | encrustations at a later stage.
Yeah; this is an obvious tradeoff. It has been pointed out that allowing an ending notation to end with + is in conflict with the old (deprecated?) +...+ chord notation. It's easy to fall into this sort of trap, since even if you can't find any use or implementation of this old notation, there will always be the fear that someone out there will suddenly start using it, because they've read an ABC "spec" from 1992 and are unaware that anything has happened since then. Lest we think this is just being silly, I might point out that it happens all the times with the warnings that keep popping up years after they were debunked. Someone stumbles across an undated document, thinks it's current, and emails it to a large crowd of equally clueless friends. But back to abc endings. The extended syntax that I've put in my clone of abc2ps now casually allows any chars in "-,.+&0123456789" as an ending string. An ending like [1,3. is a potential problem, since it conflicts with the use of the dot as an ornament. Allowing both does get a bit tricky. If we want to allow for context-free parsers, there's no way to allow both. My current code actually does allow both, by a simple and obvious kludge: It considers spaces to be significant. Consider these: |[1,3. c2d2 |] % The dot is part of the ending string |[1,3 .c2d2 |] % The dot is an ornament The basic parser does in fact allow spaces between an ornament and a following note, though I don't think this is a great idea. But there is abc out there that does this, and I want my tune finder to be able to handle them. What the parser does with the above examples is rather trivial: It eats up chars until it finds a char not in the list of acceptable ending-string chars. A space isn't in the list. In the first example, "1,3." is the ending string. In the second example, the ending string is "1,3", and the dot is left for some other part of the parser to deal with. If you were to write just |[1,3.c2d2|, I'd say that an abc tool is free to interpret the dot however it wishes. There's a lot of precedence for this sort of behavior in the lexical part of a parser. Thus, in both C and perl, spaces are generally optional around operators. But (x++ +y) is different from (x+ ++y). This is a very easy sort of distinction to make at the lexical level of a parser, and isn't a serious problems to a programmer. Chris's abc 1.6 doc already makes a similar use of spaces in the ending notation. It says that the ending digit must not be separated from the preceding [ or | by a space. This is also a bit of a kludge, but a reasonable one. We can just say that the notation for an ending must not contain spaces, and anything after a space will be considered some other musical object. Then a space can always be used to disambiguate such things. In general, it would help improve legibility if we could do things to subtly encourage use of spaces in the obvious places. One way to do this might be to look for other cases like this where we can use spaces to disambiguate parts of the notation. We can extend the use of spaces for beaming to the general idea that "Things next to each other are more closely bound together than things separated by spaces." If we use this as a guideline, the result should be abc that is more readable, and it's a simple sort of thing to program. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
