I'm working on some basic features right now, namely Optionals, Variables, and Sets, which I'll explain presently.
The basic rule format is intended to look more like sound-change rules, as they are written normally:
Code: Select all
1. a b c > x y z / P_S
Code: Select all
2. a b c > x y z / _
3. a b c > x y z
4. **a b c > z y z /
Actually, this still doesn't support word boundaries; However, it does allow comment lines starting with # and even inline-comments in ##
My current task is to correctly implement Variables; I did a sloppy job yesterday, and only the first variable in a rule actually got processed. Variables are capital letters and/or numbers preceded by @.
Code: Select all
5. @C = p t k b d g r l m n
6. @V = a e i o u
7. @PLOSIVE = p t k b d g
Code: Select all
8. @NASAL = m n
9. @LIQUID = r l
10. @SPIRANT = s z
11. @CONSONANT = @PLOSIVE @SPIRANT @LIQUID @NASAL
Optionals are strings enclosed by parens (...) indicating that the enclosed string may be present or omitted, as is the standard practice. Unlike in some other SCAs, these can be included in both the Initial and Condition, not just the Condition. an Optional in the Final will produce an error.
Finally, I'd like to allow ad hoc Sets, which basically work like Variables, but are not stored in memory. These are useful where you would otherwise use a Variable, but perhaps only the once.
I would like to allow Optionals and Sets in the Initials, but this is inviting bugs.
Some other features I'd like to add are related to some of these others. One is Many-to-One replacement:
Code: Select all
12. a e o > ə
Also, some real-world rules are hard to run using the standard find-and-replace method that this and other SCAs seem to use. Among these are things like vowel syncopation ( I know Jeff was having trouble with this with MUBA's VSCA ) because they require large strings, which means a huge search-space. Another such problem is Grassmann's law in eastern Indo-European, where an aspirated stop in a root is de-aspirated if another aspirated stop occurs later in the root. Distance assimilation/dissimilation will probably always be a problem. Here are the rules from my VSCA code for doing Grassmann's law in Kuma-Koban:
Code: Select all
VS=aeiou[ə]
VL=āēīōū[ə̄]
V=<VS><VL>
N=mn
R=rl
IU=iu
CH=[pʰ][tʰ][cʰ][kʰ]
[pʰ][tʰ][cʰ][kʰ]/bdɟg/_V(N)<CH> 576
[pʰ][tʰ][cʰ][kʰ]/bdɟg/(R)_V<IU><CH> 1152
[pʰ][tʰ][cʰ][kʰ]/bdɟg/_VR(s)<CH> 768
2496
I think I know how I could potentially solve this using regular expressions (built in, of course; I want this to be relatively user-friendly), but this will require a totally different processing mechanism than the other rules and will at least have to wait until I finish getting the basics done.
I'll try to make an alpha of some kind available as soon as I can.