Representing suprasegmentals in sound change appliers

[bradrn]

I didn't really understand what does the _* operator do, buf it's something generic and flexible - as opposed to something fixed and specific - I like it. Is it related to that quote?

Basically, a rule target / replacement / before * after would:

• Find an occurrence of before in the input
• Find the next occurrence of after
• Between those two occurrences, replace every occurrence of target with replacement

The last point is what makes it useful for spreading — V / V̈ / V̈ C* _ only replaces the first V, but V / V̈ / V̈ * would replace every V after a V̈, no matter where in the word it is. (And together with the other stuff, I hope to eventually be able to do something like V / $Round / $Round * for the complete vowel harmony rule.)

Is _* like * in regular expressions?

No it isn’t: note that _ can’t occur multiple times in most SCAs, so _* can’t be interpreted as a Kleene star. I’m willing to consider other syntax for this if _* would be too confusing (especially since Brassica already has the Kleene star).

[bradrn]

I’ve realised that it would be good to pin down the semantics of ±features in more detail, so…

(Warning: this is another one of my rambly posts, and somewhat Brassica-specific in parts. Feel free to ignore it.)

Let’s write down a very simple set of features:

V = a i o u á í ó ú
+Round = o u ó ú
-Round = a i á í
+Stress = á ó í ú
-Stress = a o i u

The tricky case is a feature assimilation rule, such as $Round V / V $Round. The intention is for the second vowel to take on the roundedness of the first: /au/→/ai/, /oi/→/ou/, etc. As zompist noted earlier, this is ‘a sort of cut and paste operation’: the first $Round causes some variable somewhere to be set to ‘+’ or ‘-’ depending on which vowel is seen, and then that gets transferred to the replacement $Round with the second vowel.

Problem: this implicitly requires some sort of correspondence between $Round and V. Somehow, the $Round in the replacement needs to know to take its value from V in the target. It could do this by position, I guess, since that’s how category matching-up already works. But my experience with Brassica’s existing half-broken attempt at a feature system suggests that merging two different kinds of things like this is a recipe for disaster (because it’s too easy to make a mistake when matching them up).

The cleanest solution would be to forbid using $features on their own. Instead, say they must always accompany some actual list of graphemes: [V $Round] V / V [V $Round]. (This is in fact how I wrote it earlier.) I like this, because it gives a clear separation of concerns: categories are for describing the overall structure of the input and the output, and features are for adjusting precisely how the two correspond to each other.

So when [V $Round] is encountered in the replacement, what exactly happens? Taking Brassica as a reference, it would first use V to find the underlying grapheme. Then it would read the setting of $Round, and alter that already-chosen grapheme to conform with the roundedness setting if it doesn’t already.

(And what if V were to contain a grapheme listed in neither +Round nor -Round? It could remain unchanged, or perhaps it could be an error. Either is justifiable, I think, though I lean towards the former.)

What if multiple features were present? As in a rule like, say, [V $Round $Stress] V / [V $Round $Stress]. I think the same procedure suffices: first find the replacement V, then force it to have the right roundedness setting, then force the result of that to have the right stress setting. Responsibility would be on the user to make sure that each feature pair preserves the other feature settings (though this is a very easy requirement to satisfy).

That settles the behaviour of $feature, I think. What about +feature and -feature? What kind of thing are those? I think it’s fine to make them ordinary categories. The only guarantee they need is that, when combined with other categories (in intersections or subtractions), the order of their graphemes is preserved. This is critical to making sound changes like [V +Round] / [V -Round] to work, but it’s easily ensured. And, with this, the ‘magic’ is confined to sound changes which use $.

Further question: if ±features are simply ordinary categories, is it possible to represent $features as ones too? How much ‘magic’ is even needed? After all, I started this conversation by establishing that $feature can be replicated in current Brassica using nested categories. Is it possible to internally simplify $features down to to regular category expressions?

Unfortunately, the answer seems to be, ‘not easily’. The issue is working out how to rewrite stuff in the target. If one writes [V $Round], then Brassica needs some way to express that $Round variable. This can be done using a nested category match, [{[a i á í]} {[o u ó ú]}]. The outer category matches $Round, the inner one matches V. Unfortunately, this completely messes up the replacement, where one expects to be able to write a simple V to transfer the grapheme to the replacement. I’m not sure it’s possible to get around this problem.

Another issue is predefinition. This is important, because nothing in current Brassica requires predefinition — it can all be expressed inline. In theory, one could invent a syntax for inline $features too: perhaps something like, [V $Round(o/a u/i ó/á ú/í)] V / V [V $Round(o/a u/i ó/á ú/í)]. I probably will allow something like this, for consistency with all the other parts of Brassica, but I don’t anticipate the syntax itself to see wide use.

---

That last point made me think of something else — what if one feature in the target corresponds to a different feature in the replacement? I wondered if this could actually happen, but then I thought of a case where it’s necessary: transphonologisation changes where, say, coda consonant voicing turns into vocalic tone. It would be nice to be able to represent this as V [C $Voice] / [V $Tone] C. This suggests that matches between target and replacement features should be made ignoring feature names — except that there are problems with this…

(Another point: sometimes you might want +Voice to correspond to -Tone, rather than +Tone. It’s probably a sensible idea to add syntax for negating the feature value, say -$Tone.)

One problem is that this complicates another idea I had — that of multivalent features. A multivalent feature for place of articulation, for instance, would mean that e.g. nasal assimilation could be expressed nicely as N [C $POA] / [N $POA] C. I hadn’t yet fully worked out all the details of how this could work, but a fairly important aspect was that a POA feature in the target would correspond only to a POA feature in the replacement, so that the feature values are transferred easily. If a POA feature in the target could correspond to, say, a Backness feature in the replacement (not inconceivable!), that would complicate matters.

Finally, circling back around to my original problem: does this help with suprasegmental or autosegmental categories? I think it does. With features as described above, an ‘autosegment’ would simply be a cross-section through a feature pair: like a/á, or o/ó. If combining a variable with a category makes a feature transfer declaration (as [V $Round]), combining a variable with a grapheme would make an autosegment (as a$Stress). This is not equivalent to a category (like [a á]), because the information travels through different ‘channels’, so to speak — a binary feature value, as opposed to a category index.

(This poses the question of whether [V $Round] shouldn’t be written as V$Round. Come to think of it, the latter is more consistent.)

Then, declaring a feature ‘autosegmental’ could simply mean that every occurrence of, say, a is reinterpreted as a$Stress, in the target and replacement (and presumably environment too, though there it’s less important). To be usable this actually requires that feature transfer should not ignore feature names as suggested earlier, because otherwise it would be too easy to accidentally transphonologise the autosegmental feature onto some other random feature which happens to be mentioned in the replacement. In this case, presumably there can be special syntax for transphonologisation when it is desired: say, V [C $Voice#ref] / [V $Tone#ref].

I feel like this notion of ‘keeping separate features separate’ is sort of what I’ve been grasping for since the beginning of Brassica. This way, each opposition which is phonologically meaningful gets its own name, allowing it to be kept separate from other oppositions by default. Meanwhile, categories give an easy way to specify groupings which don’t form any coherent opposition, or are specified on an ad-hoc basis. I like this!

[Zju]

The last point is what makes it useful for spreading — V / V̈ / V̈ C* _ only replaces the first V, but V / V̈ / V̈ * would replace every V after a V̈, no matter where in the word it is.

Nice. I had thought of something similar before: V → V̈ / V̈ , which would replace every V with a V̈, if there's one or more V̈ in a word.

[Zju]

Re $features and such, I only read about half the post, but I think at some point it's just less effort to begrudgingly write one rule as two and not go with making up new syntax:

V[-Round] → V[+Round] / _V[+Round]
V[+Round] → V[-Round] / _V[-Round]

And maaaaybe allow ± and its counterpart ∓ as a shortcut of writing the above:

V[±Round] → V[∓Round] / _V[∓Round]

And if you discard the V[...] syntax and just go with ±Round, these new groups won't even need to be associated with V.


What are some examples of hodgepodges of 'standard, plain' rules that collapse to a single, elegant rule using $features and nested notations?

[bradrn]

The last point is what makes it useful for spreading — V / V̈ / V̈ C* _ only replaces the first V, but V / V̈ / V̈ * would replace every V after a V̈, no matter where in the word it is.

Nice. I had thought of something similar before: V → V̈ / V̈ , which would replace every V with a V̈, if there's one or more V̈ in a word.

Yep, that kind of thing… the * syntax would be more general, since it allows for bounded and/or unidirectional spreading.

Re $features and such, I only read about half the post, but I think at some point it's just less effort to begrudgingly write one rule as two and not go with making up new syntax

V[-Round] → V[+Round] / _V[+Round]
V[+Round] → V[-Round] / _V[-Round]

To some extent, yes, this is true. But I think that being able to express such common sound changes in a single line is useful in and of itself. I’m thinking particularly about the Index Diachronica here: it’s quite important to be able to write down sound changes in a way which people would naturally expect.

What are some examples of hodgepodges of 'standard, plain' rules that collapse to a single, elegant rule using $features and nested notations?

The big UX improvement is with suprasegmental features (which you’ll recall are the topic with which I started this thread): ones which you want to ignore most of the time. It’s much more convenient to write, say, ə [w y] / [u i], or even ə$Stress [w y] / [u i]$Stress, than it is to write

Code: Select all

ə [w y] / [u i]
ə́ [w y] / [ú í]

which is the easiest alternative at the moment. (Or you can write it in one line as [ə ə́] [w y] / @2 [{@1 [u ú]} {@2 [i í]}], but I think you’ll agree this is unreadable.)

The other big advantage comes from the ability to do ‘feature transfer’ onto arbitrary graphemes. Going back to the vowel harmony example, V$Round C V / V C V$Round, this is actually really annoying to do in current Brassica. You have to do something like:

Code: Select all

[V +Round] C [V -Round] / [V +Round] C [V +Round]
[V -Round] C [V +Round] / [V -Round] C [V -Round]

If you haven’t actually sat down and thought through this, it’s not obvious that you need to arrange the ‘+’s and ‘-’s like this. And because it’s two rules rather than one, it has the issue that multiple applications might not do what you expect — in this case, -Round spreading will always take precedence over +Round spreading. If you don’t want this to happen, merging these lines into a single rule gets very annoying, very quickly.

And, of course, the more features you have, the more annoying it gets. If you want four-way vowel harmony (like in Turkic), with features that would just be V$Round$Front C V / V C V$Round$Front. With categories, you need eight lines, and the ± combinations are non-obvious:

Code: Select all

[V +Round +Front] C [V -Round -Front] / [V +Round +Front] C [V +Round +Front]
[V +Round +Front] C [V +Round -Front] / [V +Round +Front] C [V +Round +Front]
[V +Round -Front] C [V -Round +Front] / [V +Round -Front] C [V +Round -Front]
[V +Round -Front] C [V +Round +Front] / [V +Round -Front] C [V +Round -Front]
[V -Round +Front] C [V +Round -Front] / [V -Round +Front] C [V -Round +Front]
[V -Round +Front] C [V -Round -Front] / [V -Round +Front] C [V -Round +Front]
[V -Round -Front] C [V +Round +Front] / [V -Round -Front] C [V -Round -Front]
[V -Round -Front] C [V -Round +Front] / [V -Round -Front] C [V -Round -Front]

I’m not even sure if this is correct or not… I’m pretty sure there’s cases I’ve missed here. To be certain of covering all the cases, you’d need 16²=256 lines. I don’t really want to deal with that if there’s a way of doing it in one line.

[EDIT: on rethinking, that calculation was wrong. The number of cases is not 16², but only 4²=16. Of these, 4 cases are redundant, meaning this needs 12 lines. The above code has 8 lines, so there’s 3 cases which I missed. 12 lines isn’t unmanageable, but it’s very annoying nonetheless.]

Of course, the vast majority of cases can be easily supported by current Brassica by writing them in two lines like you say. But I think this is a reasonably convincing argument as to why the current state of affairs is unsatisfactory.

[bradrn]

I spent today implementing phonetic features, as per the design above. It was remarkably easy to do so, and from my quick tests the experience of using it seems good. I guess it pays off to actually think things through beforehand!

Tomorrow I plan to implement the additional parts of this plan: multivalent features, and autosegmental features. The latter could take a bit of thought, because this:

If combining a variable with a category makes a feature transfer declaration (as [V $Round]), combining a variable with a grapheme would make an autosegment (as a$Stress).

…turns out to be inconsistent: the only reasonable interpretation of a$Stress would be to assign Stress a constant negative value. Also, it would require the sound change to somehow know that a has alternative á or à or whatever it may be, and there’s no way of doing that sensibly. The most sensible way to get this working will probably be to add yet more syntax to work around the deficiencies in Brassica’s category system (which, by comparison to this, looks more and more hackish with every passing day).

Surprisingly, the * syntax looks like it’ll be the most difficult thing to implement, of all the syntaxes we’ve been discussing in this thread. Mostly, this is because it’s forcing me to actually think about what the semantics of right-to-left rule application should be — and it’s not proving easy.

(If anyone happens to have any materials on rule directionality in sound change, please let me know! I’d love to learn about what happens in actual natlangs.)

[bradrn]

I realised there’s something I didn’t quite think about…

categories
-Stress = a e i o u
+Stress = á é í ó ú

auto -Stress

V = a e i o u
end

The idea here is that -Stress contains all the unstressed vowels, and +Stress contains all the stressed vowels. The declaration auto -Stress means that any mention of a in a sound change will match ⟨á⟩ as well, and so on. The question is: what does V contain?

I can see three options:

1. V contains only the unstressed vowels ⟨a⟩, ⟨e⟩, ⟨i⟩, ⟨o⟩, ⟨u⟩, as listed in its definition. This is the simplest option.
2. V contains both the unstressed and the stressed vowels: ⟨a⟩, ⟨á⟩, ⟨e⟩, ⟨é⟩, ⟨i⟩, ⟨í⟩, ⟨o⟩, ⟨ó⟩, ⟨u⟩, ⟨ú⟩, because auto -Stress extends mentions to the unstressed vowels to include the stressed vowels too. This is consistent with how Brassica currently implements phonetic features.
3. Something between the above options: V will formally be considered as containing only ⟨a⟩, ⟨e⟩, ⟨i⟩, ⟨o⟩, ⟨u⟩, but will also match ⟨á⟩, ⟨é⟩, ⟨í⟩, ⟨ó⟩, ⟨ú⟩, similarly to how standaline a also matches ⟨á⟩. This is consistent with how individual graphemes work, but is more difficult to explain.

I’m leaning towards (1), or failing that (3), but I’m not entirely sure. What does everyone else here think?

[zompist]

From the perspective of someone who doesn't know Brassica... it sounds like you're doing features in a way that's not doing features.That is, you've defined á as a feature variant of a, but somehow á is not a vowel?

Also... why do you have separate definitions for Stress and V? Seems like asking for trouble when someone adds a new vowel to one but not the other.

[bradrn]

From the perspective of someone who doesn't know Brassica... it sounds like you're doing features in a way that's not doing features.

To some extent, yes. The idea is to allow the expression of sound changes involving features, without requiring a full feature specification for every single phoneme. (In the case of conlanging, that requirement is annoying; in the case of the Index Diachronica, it’s probably impossible to achieve.)

That is, you've defined á as a feature variant of a, but somehow á is not a vowel?

I’m taking this comment as evidence that my option (1) is most intuitive. That is to say, if you want V to contain á, you need to list it explicitly — it won’t be inserted for you, just because a certain feature was declared as auto.

Also... why do you have separate definitions for Stress and V? Seems like asking for trouble when someone adds a new vowel to one but not the other.

Because this is a simple, quickly-thrown-together example, that’s why! In a real set of sound changes I’d probably define V as the union of +Stress and -Stress.

(For a more plausible example, you could replace that last line with Front = a e i.)

[zompist]

That is, you've defined á as a feature variant of a, but somehow á is not a vowel?

I’m taking this comment as evidence that my option (1) is most intuitive. That is to say, if you want V to contain á, you need to list it explicitly — it won’t be inserted for you, just because a certain feature was declared as auto.

That may be intuitive for you, but it's the opposite of intuitive for me!

I'd find it really odd if a sound change like t/d/V_V didn't work because á is not taken as a vowel though it's explicitly defined.

I'm tempted to say that the program should offer some helps on defining V and C. It's very easy to define something in a rule and never add it to either set.

[Zju]

I'd find it really odd if a sound change like t/d/V_V didn't work because á is not taken as a vowel though it's explicitly defined.

This, thousand times over.

The question is: what does V contain?

I'd intuitively expect it to be the superset of V$-stress or V$+stress - or however you'd spell the latter two in Brassica.

May I suggest the following idea for this syntax:

Code: Select all

categories
-Stress = a e i o u
+Stress = á é í ó ú

auto -Stress

V = -Stress +Stress
end

[bradrn]

That is, you've defined á as a feature variant of a, but somehow á is not a vowel?

I’m taking this comment as evidence that my option (1) is most intuitive. That is to say, if you want V to contain á, you need to list it explicitly — it won’t be inserted for you, just because a certain feature was declared as auto.

That may be intuitive for you, but it's the opposite of intuitive for me!

I'd find it really odd if a sound change like t/d/V_V didn't work because á is not taken as a vowel though it's explicitly defined.

Thanks for clarifying! So that narrows it down to either (2) or (3).

Reviewing the options again… with (2), any occurrence of a in a category gets expanded out to a á. That’s simple enough to implement and understand. Alas, it’s error-prone. The issue here is that Brassica matches up categories element-by-element, but this implicitly changes the number of elements in a category. If someone were to write:

[i u] / [y w]

…then that would be silently expanded out to…

[i í u ú] / [y w]

…causing much confusion for all concerned.

This is the reason why I’m tending towards (3). With this option, i within a category behaves the same way as i outside a category: it matches both i and í, while assigning the $Stress category variable so that any vowel in the replacement will get the same stress. That behaviour is slightly complicated, especially if one happens to combine (say) vowels and consonants in a single category… but in the vast majority of cases it should produce the desired behaviour, I think. Certainly, it avoids the problems of forgetting stuff in categories (as with 1) and of category elements being silently misaligned (as with 2).

I'm tempted to say that the program should offer some helps on defining V and C. It's very easy to define something in a rule and never add it to either set.

It does offer these helps, though. You can say e.g. V = -Stress &+Stress to define V as the union of all the unstressed and stressed phonemes. My current set of sound changes defines C = Nasal Stop Affricate Fricative Approximant. And so on.

[bradrn]

May I suggest the following idea for this syntax:

Code: Select all

categories
-Stress = a e i o u
+Stress = á é í ó ú

auto -Stress

V = -Stress +Stress
end

My last post mentions that this is supported as -Stress &+Stress. (Simple -Stress +Stress would be a contradiction, because the + gets interpreted as intersection.)

[bradrn]

Another straw poll… let’s say I have a multivalent feature Tone with values Low, Mid, High. Which syntax do you prefer for writing these categories?

1. Low+Tone, Mid+Tone, High+Tone
2. +Low+Tone, +Mid+Tone, +High+Tone
3. +Tone+Low, +Tone+Mid, +Tone+High
4. Something else, please suggest!

(I’m leaning towards 3 as being a bit easier to process, but not sure if it’s the best option for the user.)

[zompist]

[*] Something else, please suggest!

+High = i u
+Mid = e o
+Low = æ a

I suppose this leaves -High etc undefined, but then I'm not sure how they would be used. E.g. I'd expect -High to match anything Mid or Low in a match, but what does a change of +High to -High do?

[bradrn]

[*] Something else, please suggest!

+High = i u
+Mid = e o
+Low = æ a

I suppose this leaves -High etc undefined, but then I'm not sure how they would be used. E.g. I'd expect -High to match anything Mid or Low in a match, but what does a change of +High to -High do?

Ah… well, the problem is that I want to group them together under a single feature name, so that I can do stuff like e.g. V$Height V / V V$Height for height harmony. This is essentially a multivalent feature, which is why -Height makes no sense — that only works for a binary feature.

[bradrn]

I decided to go with format (3), +Tone+High (with the feature value at the end), simply because it simplifies the implementation: the program can just search by string prefix to find all the categories associated with a particular feature.

[bradrn]

Autosegments are now implemented! I’ve converted the sample sound changes to use them, and it all seems to work well. I’ve been thinking of putting this latest version online as a pre-release, if anyone wants to try it out for themselves.

The only restriction on autosegments currently is that they can’t be nested. That is to say, you can’t make e.g. stress autosegmental, and then also make tone autosegmental on the same phonemes. I’m not sure that this is a problem in practice, though: how often does one really need two separate levels of implicit feature marking on a single phoneme? The only example I can think of is stress and tone, and even then, those two categories are rarely truly independent of each other.

(Note that this restriction was not present with the old way of doing phonetic features — the great advantage of their dumb category expansion is that they got this stuff ‘for free’. On the other hand, actually trying to use this is a great way to get confused and mess up your sound changes.)

[bradrn]

(If anyone happens to have any materials on rule directionality in sound change, please let me know! I’d love to learn about what happens in actual natlangs.)

Returning to this point, I found a great thesis by Howard (1973). As part of his theory on rule directionality, he describes a rule application algorithm (pp53–63) which is, remarkably, almost identical to the one used in Brassica, with the sole exception of where subsequent rule applications begin within a word. This change is all that is required to allow the replacement of one application to be used as the environment of the next.

It turns out that this ability is sufficient to represent all the tricky spreading situations from earlier, without any need for *. Thus:

(putting the new stuff in boldface, and restricting myself to LTR changes because I haven’t yet resolved RTL application)

• ‘all vowels agree in roundedness with the first vowel’: V / V$Round#env / V$Round#env C* _
• ‘consonants after a nasal must be nasalised, until a voiceless stop is reached’: -Nasal / +Nasal / +Nasal V _ (works because voiceless stops are -Nasal; for full nasal harmony can use instead -Nasl / +Nasl / +Nasl [V Nonnasal]* _)
• ‘stress every second syllable’: C* V C* V C* / C* V C* V́ C* (doesn’t actually require iteration control, if the SCA has non-overlapping targets which it still does)
• ‘stress every first syllable restarting at long vowels’: [&+Long -Stress] / [&+Long +Stress], then C* -Stress C* V C* / C* +Stress C* V C*
• Pre-Eŋes stress rule (code block in the last post): (never required * at all, can be implemented in existing Brassica)
• ‘delete all high tones before the last’: +High / -High / _ ^ +High
• ‘add an ⟨n⟩ after at least one nasal vowel’: (no longer of interest, expressible as of Brassica 0.3.0 using filter)

So, as much as I love the idea of zompist’s *, this seems simpler and very nearly as general, plus it’s in accordance with the literature. I think I’ll be going with this approach, then. (Of course, the situation would be different if anyone can suggest a case where * is more powerful.)

[bradrn]

Cross-posting due to relevance:

I’ve uploaded a prerelease of Brassica here: https://bradrn.com/brassica-1beta/. Feel free to play around with it! (The ‘Tonogenesis’ example in particular shows off the new feature system. Also see the test changes.)