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

Reply via email to