Lexurgy Sound Changer Tutorial — Using Features

Everything so far has treated sounds as indivisible units. But Lexurgy also lets you break down sounds into the features that describe them, allowing certain kinds of complex sound changes to be written more efficiently and robustly.

When to Use Features

Features can take quite a bit of effort to set up, so it's usually best to start a project without using features. Bring features in when:

• You want to use IPA diacritics.
• You need to deal with suprasegmentals like tone, stress, or vowel length, or secondary articulations like palatalization.
• You have several assimilation or dissimilation rules that are bulky and hard to read.

Binary Features

Let's look at an example of a simple vowel space defined using binary features, as used in distinctive feature theory:

This example defines four features: low, high, front, and back, representing the position of the tongue in the mouth when making that vowel. Each of these features has two values: low has the value +low for low vowels like [a], and the value -low for non-low vowels. It then defines a symbol for each vowel in the language, and gives each vowel a feature matrix, showing which feature values that vowel has. Now, anytime Lexurgy encounters an [e] in a word, it knows that that [e] is a front vowel, but not a low, high, or back vowel.

The final-vowel-raising rule uses these features to change all mid vowels (which are -low -high) to the corresponding high vowel. The matrix [+high] on the result side of the rule means that the high feature, and only the high feature, will be changed to +high, while all other features (like the front and back features) are left unchanged.

Absent Values

Binary features actually have a third value: absent, written with a * before the feature name. (This makes the name "binary" rather suspect... linguistic terminology can be confusing sometimes!) So the absence of the low feature is written *low and the absence of the back feature is written *back. Any character that you haven't explicitly given a value for the low feature automatically has *low. This would most likely be the case with any consonant sounds, where the low feature is irrelevant.

You can use absent features in rules just like any other feature value:

Any characters in an input word that don't match symbols are considered to lack all features, so they'll only match matrices consisting entirely of absent features, like [*low *front], or the wildcard [].

Univalent Features

You can also define univalent features, which only have two values: present and absent.

The feature nasalized has only the two values +nasalized and -nasalized. Any sound that isn't explicitly defined to be +nasalized is automatically -nasalized. There's no separate *nasalized value—*nasalized is just another way of writing -nasalized.

Multivalent Features

Lexurgy also allows features with any number of values. For example, you can recreate part the IPA consonant chart like this:

This defines three features: voicing, place, and manner. With multivalent features, each value has a name; rather than writing [+place] or [-manner], which wouldn't make sense, you have to use the names, like [labial nasal].

Just like binary and univalent features, multivalent features always have an absent value. In this example, we didn't specify a voicing for [m], [n], and [l], so they automatically have the absent value *voicing.

Naming the Absent Value

You can give the absent value of any multivalent feature a name. The above example could also be written:

Then all sounds are automatically voiceless unless you explicitly declare them to be voiced.

Feature Variables

Languages often undergo assimilation, where one sound becomes more like a nearby sound. Lexurgy provides feature variables to make assimilation rules easier to write. Feature variables copy a feature value from one sound to another:

The [consonant $place] matrix in the environment matches any consonant, but captures the value of that consonant's place feature. This feature value is copied into the matching $place in the output matrix.

Beware of matrices containing only feature variables! The matrix [$place] matches any sound and blithely copies its place feautre, even if its value is *place. This can easily lead to errors:

Since vowels aren't declared to have a place, the rule copies *place from the a in amata onto the m, obliterating its place of articulation and producing the non-existent sound [nasal consonant].

Negated Values

You can match any sound that doesn't have a given feature by putting ! before the feature value.

This is often useful if there are gaps in the symbol chart. Suppose you want to voice fricatives between vowels, and write these rules:

This causes an error, since [h] has no voiced counterpart. To fix this, you can indicate that only non-glottal fricatives voice:

Diacritics

The IPA indicates some features explicitly using diacritics: [ʰ] indicates aspiration, [ː] makes a vowel long, [ ̥ ] makes a sound voiceless, and so on.

You can define such diacritics in Lexurgy like this:

If the base symbol has a feature matrix defined, the diacritic will overwrite any conflicting values, while leaving all other values intact:

Notice that Lexurgy only uses diacritics when necessary: it uses the -voiced diacritic to represent voiceless nasals, but doesn't try to represent [-voiced labial stop] as p̥, since b is already defined with that matrix.

You can also choose how diacritics are attached to their base symbol: (before) makes the diacritic go before the base symbol, while (first) makes it go after the first character of the base symbol.

Floating Diacritics

By default, diacritics create an entirely new sound. In this example, the aspirated stops are unaffected by the intervocalic-voicing rule:

But some features are more superficial. You'd normally expect [á] ([a] with a high tone) and [aː] ([a] held for longer) to follow the same sound changes as plain [a]. To indicate this, mark the diacritics as (floating):

If you want a particular rule to only affect plain [a], put ! after it:

Ignoring Floating Diacritics in Capture Variables

Capture variables normally don't pay attention to features—they copy entire sounds. But that means they won't match sounds that differ only by floating diacritics:

You can fix this with an inexact capture variable, marked with ~$ instead of $: