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