Re: [abcusers] new BNF spec
Buddha Buck wrote: T.M. Sommers wrote: henrik wrote: There is one serious problem with changing the BNF spec to literal strings being case sensitive - places where we don't want case sensitiveness become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all be allowed, but the BNF for case insensitive of that would be (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. This should not be unreadable to any programmer at all familiar with regexps; it is a common idiom. Too bad we are dealing with regexps then... I think something like /dor(ian)?/i is more readable, and regexpy. It's just a perl pattern, after all. Unfortunately, that won't work in lex; case sensitivity is a global property, and can't be turned on and off for different patterns. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
Well, it's case sensitive. ABNF quoted strings, e.g. A: are not case sensitive. ABC is (mostly) a case senstive language. So if I want to stick to ABNF, which happens to be a standard, I'll have to use e.g. %x58.3A and have a comment X: after it. Please use strings like A: as you did in your previous BNF definitions, and make an annotation that all strings are case sensitive. %x58.3A is so unreadable that it really pays to break the ABNF standard in this respect. Any other comments from the list on this? Should I change the BNF to case sensitive using character strings instead, or would that cause problems creating parsers using e.g. lex and yacc? /Henrik To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
henrik wrote: Well, it's case sensitive. ABNF quoted strings, e.g. A: are not case sensitive. ABC is (mostly) a case senstive language. So if I want to stick to ABNF, which happens to be a standard, I'll have to use e.g. %x58.3A and have a comment X: after it. Please use strings like A: as you did in your previous BNF definitions, and make an annotation that all strings are case sensitive. %x58.3A is so unreadable that it really pays to break the ABNF standard in this respect. Any other comments from the list on this? Should I change the BNF to case sensitive using character strings instead, or would that cause problems creating parsers using e.g. lex and yacc? Perhaps someone should write a program that parses BNF and converts it to ABNF... ;-) -- Bert Van Vreckem http://flanders.blackmill.net/ Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. -- Dave Barry To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
There is one serious problem with changing the BNF spec to literal strings being case sensitive - places where we don't want case sensitiveness become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all be allowed, but the BNF for case insensitive of that would be (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. This is just a simple example. So I'll let it keep the %x44 type notation for characters. I think I have added comments for all of these. /Henrik To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
henrik wrote: There is one serious problem with changing the BNF spec to literal strings being case sensitive - places where we don't want case sensitiveness become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all be allowed, but the BNF for case insensitive of that would be (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. This is just a simple example. So I'll let it keep the %x44 type notation for characters. I think I have added comments for all of these. /Henrik To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html There need not be any problem here. Allow both upper and lower case characters and convert where required. The tune scoring mode (among the 7 'Greek' modes recognized by ABC) occurs only as the X at the end of the 'K:key X' specification. The meaning of X is determined in a subroutine (= the working part of a macro). Let your program's internal identifier for modes be Y(n), (n=1-7), = ion, mix, dor, ael, phy, or loc, respectively, which exhausts the possibilities. Convert the X string to all lower case then trim to the first 3 non-blank characters = x. A single additional command then searchs for x in the Y(n). If this command doesn't determine a unique n' in the range of 1 to 7, then the tune is improperly coded, but with correct tune coding then you will get an n' (such that Y(n') = x) uniquely determining the scoring mode, and this implies nothing elsewhere in the ABC as far as upper or lower case letters go. Bruce Olson -- Roots of Folk: Old British Isles popular and folk songs, tunes, broadside ballads at my website A href=http://www.erols.com/olsonw; Click /a To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
henrik wrote: Well, it's case sensitive. ABNF quoted strings, e.g. A: are not case sensitive. ABC is (mostly) a case senstive language. So if I want to stick to ABNF, which happens to be a standard, I'll have to use e.g. %x58.3A and have a comment X: after it. Please use strings like A: as you did in your previous BNF definitions, and make an annotation that all strings are case sensitive. %x58.3A is so unreadable that it really pays to break the ABNF standard in this respect. Any other comments from the list on this? Should I change the BNF to case sensitive using character strings instead, or would that cause problems creating parsers using e.g. lex and yacc? Since lex is case-sensitive, that should not be a problem. lex doesn't understand things like `%x58.3A' anyway, so using strings in the grammar should make things easier. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
henrik wrote: There is one serious problem with changing the BNF spec to literal strings being case sensitive - places where we don't want case sensitiveness become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all be allowed, but the BNF for case insensitive of that would be (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. This should not be unreadable to any programmer at all familiar with regexps; it is a common idiom. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
T.M. Sommers wrote: henrik wrote: There is one serious problem with changing the BNF spec to literal strings being case sensitive - places where we don't want case sensitiveness become horribly complicated! E.g. dor dorian DOR Dor Dorian etc should all be allowed, but the BNF for case insensitive of that would be (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. This should not be unreadable to any programmer at all familiar with regexps; it is a common idiom. Too bad we are dealing with regexps then... I think something like /dor(ian)?/i is more readable, and regexpy. It's just a perl pattern, after all. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
Bruce, I think you misunderstood what I meant. I was talking about how to write it in BNF, not how to do it programmatically, which is obvious to any programmer, e.g. 0==strnicmp(key, dor, 3) Bruce Olson wrote: There need not be any problem here. Allow both upper and lower case characters and convert where required. The tune scoring mode (among the 7 'Greek' modes recognized by ABC) occurs only as the X at the end of the 'K:key X' specification. The meaning of X is determined in a subroutine (= the working part of a macro). Let your program's internal identifier for modes be Y(n), (n=1-7), = ion, mix, dor, ael, phy, or loc, respectively, which exhausts the possibilities. Convert the X string to all lower case then trim to the first 3 non-blank characters = x. A single additional command then searchs for x in the Y(n). If this command doesn't determine a unique n' in the range of 1 to 7, then the tune is improperly coded, but with correct tune coding then you will get an n' (such that Y(n') = x) uniquely determining the scoring mode, and this implies nothing elsewhere in the ABC as far as upper or lower case letters go. Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://www.norbeck.nu/ My home page http://www.norbeck.nu/abcmus/ AbcMus player program http://www.norbeck.nu/abc/ 1900 ABC tunes http://www.norbeck.nu/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish trad music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
On Mon, 7 Jul 2003, henrik wrote: (d/D) (o/O) (r/R) [(i/I) [(a/A) [n/N]]] which is quite unreadable. Personally I do not have anything against the notation above. So I'll let it keep the %x44 type notation for characters. I can read the alphabet, but I cannot make sense of hexadecimal cryptography, nor can Lex or Yacc. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
Irwin Oppenheim wrote: 1/ Is this definition your own, private proposal, or is it based on a (preliminary) draft prepared by Guido? It's my own preliminary proposal. I haven't received anything from Guido. Of course it has to be modified, but it's a starting point, because most of it will be as it is there. 2/ %x58.3A is VERY difficult to read. Could you please use alphanumeric notation such as 'X' ':' instead? I don't see any benefit of this hexadecimal notation... Well, it's case sensitive. ABNF quoted strings, e.g. A: are not case sensitive. ABC is (mostly) a case senstive language. So if I want to stick to ABNF, which happens to be a standard, I'll have to use e.g. %x58.3A and have a comment X: after it. Henrik Norbeck, Stockholm, Sweden [EMAIL PROTECTED] http://www.norbeck.nu/ My home page http://www.norbeck.nu/abcmus/ AbcMus player program http://www.norbeck.nu/abc/ 1900 ABC tunes http://www.norbeck.nu/blackthorn Irish trad music band http://www.rfod.se/folklink/ Links to Swedish trad music To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
On Sun, 6 Jul 2003, Henrik Norbeck wrote: It's my own preliminary proposal. I haven't received anything from Guido. Of course it has to be modified, but it's a starting point, because most of it will be as it is there. Thank you for your good work. Well, it's case sensitive. ABNF quoted strings, e.g. A: are not case sensitive. ABC is (mostly) a case senstive language. So if I want to stick to ABNF, which happens to be a standard, I'll have to use e.g. %x58.3A and have a comment X: after it. Please use strings like A: as you did in your previous BNF definitions, and make an annotation that all strings are case sensitive. %x58.3A is so unreadable that it really pays to break the ABNF standard in this respect. If you still wish to maintain the official BNF definition according to the strict ABNF standard, then please provide a readable variant for practical use. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] new BNF spec
On Sat, 5 Jul 2003, Henrik Norbeck wrote: I've now updated the BNF specification for ABC 2.0 http://www.norbeck.nu/abc/bnf/abc20bnf.htm 1/ Is this definition your own, private proposal, or is it based on a (preliminary) draft prepared by Guido? 2/ %x58.3A is VERY difficult to read. Could you please use alphanumeric notation such as 'X' ':' instead? I don't see any benefit of this hexadecimal notation... Irwin To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
