Alpha notation or alternatives

[mbartelsm]

One of my favorite things about this project is the way it handles featural phonetics. However, as noted in the manual, it has no direct way of handling assimilation.

Currently, the only software I know that does a good job at handling this kind of problem is Geoff's SCA (see the section on Blends), unfortunately it has no support for phonetic features and does a poor job at handling multi-character segments. His approach might serve as inspiration or at least as a referent as to what this request is about.

---

PS: I love this project, I've been following it since it was still called Phonix, keep up the good work!

[arseniiv]

Personally, I find the syntax from Geoff’s SCA difficult, and he even says specifically that blends are the trickiest to understand. Instead, I would suggest something like simple pattern matching, i. e. we can make the example rule from the manual

[+con, -son, -voice] > [+voice] / _[+con, +voice]

to be more general by assigning whether the consonant following the source is voiced, to a variable x, and using the value of x in the target:

[+con, -son] > [x:voice] / _[+con, x:voice]

This would assimilate an obstruent to be as voiced/unvoiced as a following consonant.

In this proposal, one would be able to match on feature values in the source and the condition, and apply these values in the target. Here, both the matching and the application use the same syntax ‹feature variable›:‹feature› (of course you can pick any other), with feature variables only defined in such constructs and nowhere else (so e. g. their names won’t clash with normal variable names). Another example:

[+con, x:voice][+con][+con, y:cnt] > [$2 x:voice, y:cnt]

This one should replace a triple of consonants with a single consonant, with voicedness of the first one, continuedness of the third one, and all the other feature values from the second one. (I don’t think the syntax [$2 ‹features›] is correct but I haven’t found it in the manual how to specify to which segments from the source to apply new feature values.)

(Matching on a feature of one type and then using the variable to change the feature of another type would obviously need to be a static error; and I could suggest warning the user when they do that thing with features of compatible types, like in [x:voice] > [x:con], as that still may often be not what the user have intended.)

What do you think?

(P. S. I like this project too! And I used its old predecessor, ASCA, several times, though I was mainly experimenting with transliteration (and it worked quite well) or with “migrating” words from a language to a hypothetical a posteriori language, using weird unnatural rules to make sure borrowings would not be too obvious.)