Representing suprasegmentals in sound change appliers

[alice]

So, if we take this problem as solved, the remaining problem is how to represent suprasegmentals. I’m starting to think that this problem is bound up with that of representing features more generally, which is an area where Brassica is less complete than I’d like. I’ll have to further ponder whether there’s any way of doing this which doesn’t require endless feature lists for every single phoneme.

This is pretty much where I ended up after much thinking about the problem, too.

[zompist]

Having thought about it, I believe that zompist’s * notation actually does solve my problem! I’m not sure if my interpretation is precisely the same as what zompist meant, but it does indeed seem to cover all the cases.

You indeed got what I meant.

The application algorithm would be as follows, highlighting in bold where it’s different from the usual algorithm:

1. Start at the beginning of the word.
2. Search forward until the LHS matches.
3. Continue searching (possibly skipping graphemes) until the target or RHS matches:
   • If the RHS matches, go to step 4.
   • If the target matches, replace it with the replacement and repeat step 3.
4. Repeat steps 2–3 until reaching the end of the word.

You'd surely find this in implementation, but one step is missing: either you have to make sure the RHS matches, or discard the changes if you get to the end without ever finding the RHS.

[bradrn]

Having thought about it, I believe that zompist’s * notation actually does solve my problem! I’m not sure if my interpretation is precisely the same as what zompist meant, but it does indeed seem to cover all the cases.

You indeed got what I meant.

Great!

The application algorithm would be as follows, highlighting in bold where it’s different from the usual algorithm:

1. Start at the beginning of the word.
2. Search forward until the LHS matches.
3. Continue searching (possibly skipping graphemes) until the target or RHS matches:
   • If the RHS matches, go to step 4.
   • If the target matches, replace it with the replacement and repeat step 3.
4. Repeat steps 2–3 until reaching the end of the word.

You'd surely find this in implementation, but one step is missing: either you have to make sure the RHS matches, or discard the changes if you get to the end without ever finding the RHS.

This is partly covered by the first conditional in (3). As for discarding the changes, I was thinking the RHS should be optional (since most changes will be of the form ‘spread until RHS is found’)… but then again, there’s already syntax for optionality, so I suppose that making it mandatory would be more general.

[bradrn]

This is partly covered by the first conditional in (3). As for discarding the changes, I was thinking the RHS should be optional (since most changes will be of the form ‘spread until RHS is found’)… but then again, there’s already syntax for optionality, so I suppose that making it mandatory would be more general.

On second thought… you know what, making the RHS optional actually is the best approach here. To see why, consider a reasonably simple spreading sound change with a right boundary: e.g., ‘spread nasality rightwards stopping at a voiceless stop’. But really, this statement is slightly simplified — it should be, ‘spread nasality rightwards stopping at a voiceless stop or the end of the word’. The sound change doesn’t suddenly fail to apply if a word contains no voiceless stop. And every other sound change I can think of works the same way. Sure, you could specify [Stop -Voiced #] as the RHS, but it seems so pointless to require this extra complexity for every single rule. (Besides, I believe making the RHS optional simplifies the implementation a bit.)

While I’m writing, I just realised there’s another edge case: what happens if both the RHS and the target match at the same time? Or if the RHS matches midway through the target? It’s something which we should consider, although I’m not sure if there’s any plausible sound changes which would actually trigger such an issue. Perhaps I’ll find one when I’m less tired…

[bradrn]

While I’m writing, I just realised there’s another edge case: what happens if both the RHS and the target match at the same time? Or if the RHS matches midway through the target? It’s something which we should consider, although I’m not sure if there’s any plausible sound changes which would actually trigger such an issue. Perhaps I’ll find one when I’m less tired…

Oh, actually… you know what, I gave an example of this already:

Vlong / V́long, then C* V C* V C* / C* V́ C* V C* / * V́

(If one assumes that V also matches V́, which it should.)

An example of a problematic word here would be pataa → patáa after the first rule. The first C* V C* V C* can match patáa, changing it to pátáa. But this is wrong: the match should be prevented by the fact that the rule is bounded on the RHS by V́.

So, it seems that the matching algorithm needs some modification, to account for this case where ‘both the RHS and the target match at the same time’. Probably the easiest approach is to find the bounds first (by scanning right until a match is found), and then ensuring that any matches occur within these bounds. That’s slightly more complicated than what I suggested, but more predictable, which is important.

[bradrn]

So, if we take this problem as solved, the remaining problem is how to represent suprasegmentals. I’m starting to think that this problem is bound up with that of representing features more generally, which is an area where Brassica is less complete than I’d like. I’ll have to further ponder whether there’s any way of doing this which doesn’t require endless feature lists for every single phoneme.

This is pretty much where I ended up after much thinking about the problem, too.

Since we’re agreed on this point, I’ve been thinking a bit more about features in SCAs. And I should write down my thoughts…

(Note: this has ended up long and rambly, like so many of my posts. Skip to the end if you want to see my new proposal for Brassica.)

Probably the best place to start is by outlining Brassica’s current approach. It’s a very simple (perhaps simplistic) approach: everything is done with simple ordered lists of graphemes. Ad-hoc categories in sound changes are lists, and named categories are simply exactly the same thing, but given a name so they can be reused. Categories in the target and the replacement are matched up one-to-one, and their elements are matched up one-to-one as well. If the replacement has fewer elements than the target, any missing elements are mapped to � (U+FFFD).

On this foundation, Brassica simulates features by allowing set-theoretic operations on categories: unions, intersections and subtractions. Thus, one can write sound changes such as [Fric -Vcd] / [Fric +Vcd] / V _ V, which appear featural while not requiring a full feature system.

This approach has two major disadvantages:

1. It depends very strongly on the ordering of graphemes within a category. If Fric happens to have its voiceless consonants listed in a different order to the voiced ones, then that sound change will produce unexpected results in non-obvious ways.
2. The concept of a feature isn’t actually a part of the SCA. Thus, ‘feature transfer’ changes like assimilation or spreading are annoying to write: instead of saying ‘the next vowel takes the rounding of the previous one’, you must say ‘unrounded → unrounded, rounded → rounded’ as two separate steps.

What are the essential components of a feature system which solves these problems? Taking Lexurgy as a reference point, it lets you define features (which can be binary or multivalent), then assign each phoneme a set of feature values. Thus each feature value becomes, essentially, an unordered set of phonemes. The key point which makes this work is that every phoneme is uniquely defined by its feature values: thus, a feature matrix in the target and a feature matrix in the replacement can trivially match up their elements, without requiring the user to define an ordering.

The biggest problem with this sort of feature system is, quite simply, that it’s really really annoying. Every single phoneme needs to be uniquely defined by its features — so you sometimes need to add useless features simply to keep phonemes apart. Out of necessity, the syntax is also horribly verbose, because every phoneme needs its own list of feature values.

A more subtle problem is that it gives two ways to do the same thing. Conceptually speaking, [+nasal] should be the same thing as [m n ŋ], usable in the same ways. But (at least in Lexurgy) the former is a feature matrix while the latter is a list of phonemes. And, to my understanding, the two can’t be mixed: if a rule acts on all stops plus /s/, you can’t write [+stop s] directly.

So: is there some way of solving the problems (1) and (2) without requiring a full feature system?

Taking (2) first, there actually is a clever way to work around this in current Brassica. One can write:

[{[e i a ɯ]} {[œ y o u]}] C [{[e œ]} {[i y]} {[a o]} {[ɯ u]}] / [{[e i a ɯ]} {[œ y o u]}] C @1 [{@4 [e i a ɯ]} {@4 [œ y o u]}]

This is, of course, a disgusting unreadable hack. The basic idea is to make nested categories, such that outer category @1 matches the roundedness of the first vowel, and outer category @4 matches position in the vowel space. Then the nested categories in the replacement just recombine those in a different way.

It can be made much more readable by defining named categories:

[{Unrounded} {Rounded}] C [{[e œ]} {[i y]} {[a o]} {[ɯ u]}] / [{Unrounded} {Rounded}] C @1 [{@4 Unrounded} {@4 Rounded}]

This makes it clear that the most ‘hackish’ part is abstracting away the roundedness of the second vowel. You can define categories Unrounded and Rounded, but you can’t talk about a single element across both Unrounded and Rounded.

The alternative is simply matching V, then map all its elements separately to Unrounded or Rounded categories:

[{Unrounded} {Rounded}] C [Unrounded Rounded] / [{Unrounded} {Rounded}] C @1 [{@4 Unrounded Unrounded} {@4 Rounded Rounded}]

This is better, but note that I needed to decompose V into a union of [Unrounded Rounded] to ensure that all the ordered lists end up with the same order. (Or write V with an order which just happens to work, but that’s fragile.)

In fact, this reveals that the problem here is actually the same as (1). In both cases, the issue is setting up a correspondence between two category sets. In (1), I need to map +Vcd to -Vcd. Here, I need to map V to Rounded or Unrounded.

Perhaps the answer is to get away from trying to express everything in terms of order-preserving set operations. Instead, oppositions could be defined manually:

+Vcd = p t k f s
-Vcd = b d ɡ v z

-Round = e i a ɯ
+Round = œ y o u

Where, as a sanity check, Brassica would ensure that these lists have the same number of elements. Of course, this doesn’t eliminate ordering issues entirely, but it makes it really clear that the two lists should line up. Then a construction like [Fric +Vcd] can simply use the ordering of +Vcd.

The disadvantage is one no longer gets the complement ‘for free’, simply by defining Vcd. The idea was nice, but clearly it doesn’t work in practice. And after all it’s not a bad idea for -Vcd to get its own independent existence, rather than being simply a subtraction from something else.

Note the key difference from a true feature system: this doesn’t require every grapheme to have unique feature assignments (indeed the opposite is expected). Additionally, these are all just regular categories — you can write [+Vcd s] if you want.

But, because Brassica would now know about these binary oppositions between categories, this opens up the opportunity of explicitly matching things by their feature value. This makes the above assimilation rule much easier to write:

[V $Round] C V / V C [V $Round]

(Where by default the features get matched up one-to-one between target and replacement, like categories.)

Overall… I think I really like this design, actually. I feel that my philosophy with Brassica is to avoid relying on ‘all-encompassing’ concepts which force things to be done in one specific way: like all-encompassing feature matrices, or all-encompassing syllabification rules. Requiring use of ordered set operations is a similar constraint, and I’m not sorry to get rid of it.

(Well, maybe not get rid of it totally… I may keep it in some capacity for those cases where it’s useful.)

But anyway, all this is just my opinion. What does everyone else here think?

[alice]

Here's a bit of rambling about SCAs in general, which bradrn's last post prompted me to generate.

I have a feeling that, somewhere between all the various SCAs that we've written, the One True SCA is struggling to get out; or, put another way, in trying to solve the same problems from different directions, we're coming up with not-all-that-different implementations of the same solutions. I'm not familiar with brassica, but your suggestion for features is similar enough to how my SCA does it to make me itchy, but just different enough to be incompatible. I'm sure there's a moral in there somewhere!

Personally, I feel that a usable and flexible SCA should be able to work at the level of individual features, which can be binary or multivalued. There therefore need to be ways to specify them and define how they change, and to build up phonemes and phoneme classes from them, and so on. This points to a kind of SCA feature-oriented core, upon which can be built mechanisms for feature-specific sound changes, and thence to higher-level mechanisms for (for example) matching phonemes in series and parallel, overlapping matches, can be built. You will no doubt be surprised to know that this is essentially how my SCA came about. No doubt other SCAs have originated from different motivations.

I'm not sure what the end-point of all this rambling is; it seems to be coming back to the perennial question "Does the world need several individual SCAs, or one which does everything all the others do?". This provokes other questions, like "to what extent are (a subset of) all the SCAs really the same thing with different implementations according to the implementors taste and choice of programming language?". More pertinently, if one SCA has M capabilities and another has N, will combining them provide N+M capabilities, N*M, or something else?

Anyway, that's enough.

[zompist]

Where, as a sanity check, Brassica would ensure that these lists have the same number of elements.

By this standard, most languages are insane. E.g. English [n m l r] are voiced and have no phonemic unvoiced equivalents. Vowel systems can be quite unbalanced.

This makes the above assimilation rule much easier to write:

[V $Round] C V / V C [V $Round]

If I'm following, you're using $ in a different sense in target and replacement. That is, in the target $Round basically means "remember whatever the [Round] value of this element is", and in the replacement it means "set [Round] to the value you remembered." You're setting up a sort of cut and paste operation with a clipboard.

Which will probably work, but might be unexpectedly complicated if you have multiple features involved— e.g. if you have to handle both roundness and height. (And what would you do if you needed to handle two vowels with roundness? E.g., and I don't know if this ever happens, but you want V1 and V2 to interchange their roundness values.)

I'd also note that you're redefining concatenation. Above you said that [+stop s] is a union of the phonemes with [+stop], plus s. But [V $Round] does not mean a union of all vowels with all things that have a roundness value. Which might be a silly thing to have, but the point is, when you redefine an operation contextually, there will probably be cases where the program's interpretation is not the one the user wanted.

You might consider something like

V1 C V / V C V[V1.Round]

That is, distinguish "union" from "feature lookup", and have a way of marking which element you're drawing from.

[zompist]

"Does the world need several individual SCAs, or one which does everything all the others do?".

Does the world need several auxlangs, and if not, how do you stop them?

SCAs are going to get written, because they're an interesting but not overwhelming programming exercise, and if you can code, it's more fun to write one than to pester the creators of other SCAs to rewrite them.

[bradrn]

I have a feeling that, somewhere between all the various SCAs that we've written, the One True SCA is struggling to get out; or, put another way, in trying to solve the same problems from different directions, we're coming up with not-all-that-different implementations of the same solutions.

Oh yes. Of course, whatever the One True SCA may be, I’m convinced that it would look something like Brassica. The trouble is, you think it would look very much like your own SCA. And someone else thinks it looks like Lexurgy. And on it goes…

Personally, I feel that a usable and flexible SCA should be able to work at the level of individual features, which can be binary or multivalued. There therefore need to be ways to specify them and define how they change, and to build up phonemes and phoneme classes from them, and so on. This points to a kind of SCA feature-oriented core, upon which can be built mechanisms for feature-specific sound changes, and thence to higher-level mechanisms for (for example) matching phonemes in series and parallel, overlapping matches, can be built. You will no doubt be surprised to know that this is essentially how my SCA came about. No doubt other SCAs have originated from different motivations.

I don’t think it’s an accident that so many SCAs have ended up being built on features. It is a very natural approach to representing phonology, and basically every current phonological theory implicitly assumes some sort of underlying feature system.

The trouble is, I don’t like features! Mostly due to the UX issues I’ve already mentioned. On the big continuum from ‘principled and annoying’ to ‘unprincipled and convenient’, Brassica comes down strongly on the latter, whereas your SCA and Lexurgy tend to be more towards the former. (Which is interesting, because in actual programming, I quite like principled languages like Haskell.)

There’s also the little issue that, in the diachronic literature, people rarely bother using features in any sort of consistent way. And, of course, one of the primary goals for Brassica is to be a foundation for the Index Diachronica Redux, so being able to accurately transcribe sound changes from papers is very important. (It’s what set off this whole discussion, after all.) I imagine that a lot more editorialising would be necessary to fit these sound changes into your SCA or Lexurgy.

I suspect that if someone could crack the problem of making a feature system which is actually usable, we’d be a long way towards the One True SCA. My last post was my own contribution towards this problem, but it’s hardly a complete solution…

I'm not sure what the end-point of all this rambling is; it seems to be coming back to the perennial question "Does the world need several individual SCAs, or one which does everything all the others do?".

There’s a recent comment of chris_notts’s that’s relevant here:

I still think that mine is/was really good, but the great problem with SCAs is that while everyone thinks theirs does it best, there's not a huge user pool and distributing / maintaining / supporting / hosting stuff is a thankless task. I did host a Javascript UI for it for a while, but eventually... *shrug*

It’s really easy to write SCAs; it’s much harder to get other people to use them. And the conlanging sort of programmer is one which is predisposed to getting a really bad case of ‘Not Invented Here syndrome’…

The upshot of which is that everyone much prefers to write their own SCA than to use a pre-existing one. So, no, I don’t think the world needs more than one SCA, but we’ve got 50 or so anyway, most with only a handful of users. It’s hard to say what to do about this situation.

Another perspective: does the world need more than one programming language? In one sense, no, we could all get along with just one. (Probably Lisp.) In another sense, yes, absolutely it’s important to have more than one language, because different people think differently.

[bradrn]

Where, as a sanity check, Brassica would ensure that these lists have the same number of elements.

By this standard, most languages are insane.

Hasn’t this already been well-established?

E.g. English [n m l r] are voiced and have no phonemic unvoiced equivalents. Vowel systems can be quite unbalanced.

Yeah… it’s a problem. But it’s a problem for all feature systems — e.g. in Lexurgy’s example, /m n l/ are neither voiced nor unvoiced! Presumably this solution will work for Brassica too.

This makes the above assimilation rule much easier to write:

[V $Round] C V / V C [V $Round]

If I'm following, you're using $ in a different sense in target and replacement. That is, in the target $Round basically means "remember whatever the [Round] value of this element is", and in the replacement it means "set [Round] to the value you remembered." You're setting up a sort of cut and paste operation with a clipboard.

Yes, correct. This is precisely the same as how category backreferences already work. If there are multiple features, probably I’ll keep them separate by default (with syntax to change that if necessary).

I'd also note that you're redefining concatenation. Above you said that [+stop s] is a union of the phonemes with [+stop], plus s. But [V $Round] does not mean a union of all vowels with all things that have a roundness value. Which might be a silly thing to have, but the point is, when you redefine an operation contextually, there will probably be cases where the program's interpretation is not the one the user wanted.

Well… it’s a little more complicated than that: Brassica already uses initial punctuation marks as set operations. Currently [X Y] is union, [X +Y] is intersection, and [X -Y] is subtraction. This change does underlyingly redefine concatenation, so I’ll need to think up some new syntax, but at the surface level it looks basically the same.

[alice]

"Does the world need several individual SCAs, or one which does everything all the others do?".

Does the world need several auxlangs, and if not, how do you stop them?

One could argue that, on a very abstract level, an SCA is really a kind of auxlang. This is left as an exercise for the reader.

SCAs are going to get written, because they're an interesting but not overwhelming programming exercise, and if you can code, it's more fun to write one than to pester the creators of other SCAs to rewrite them.

A salutary observation. bradrn's analogy with programming languages is also pertinent: just about every new programming language carries with it the subtle insinuation that "All you others are mistaken in your assumptions; I'm going to get it RIGHT this time".

Oh yes. Of course, whatever the One True SCA may be, I’m convinced that it would look something like Brassica. The trouble is, you think it would look very much like your own SCA. And someone else thinks it looks like Lexurgy. And on it goes…

Well, obviously! (see above)

[Zju]

[V $Round] C V / V C [V $Round]

[...] But anyway, all this is just my opinion. What does everyone else here think?

In what ways are linguists writing down such sound changes? I think going by current usages is always a good starting point.

Either way, I dislike writing immutable stuff in source and target. Maybe I'd go with:

Code: Select all

V → V[+Round] / V[+Round]C*_
V → V[-Round] / V[-Round]C*_

Alternatively - if one maintains that this should be a single line - somethinng akin to what Zompist suggested (for the same reasons, and for clarity's sake):

Code: Select all

V[Round] → V.1[Round] / V.1-C*_

(yes, that's impromptu usage of Leipzig GR . and -)


What I do miss from about every SCA syntax is specifing the 'next to' sort of conditions. E.g. velars turning into uvulars next to low vowels:

Code: Select all

K → Q / LOW_
K → Q / _LOW

Why not just write that as K → Q / |LOW| ?

[bradrn]

[V $Round] C V / V C [V $Round]

[...] But anyway, all this is just my opinion. What does everyone else here think?

In what ways are linguists writing down such sound changes? I think going by current usages is always a good starting point.

For simple sound changes, they use A→B/C_D format. For more complicated ones, they tend to avoid symbols and write everything in text. Naturally, the latter is unhelpful for SCAs — so I want to find a notation which corresponds reasonably closely to how things are usually phrased.

Alternatively - if one maintains that this should be a single line - somethinng akin to what Zompist suggested (for the same reasons, and for clarity's sake):

Code: Select all

V[Round] → V.1[Round] / V.1-C*_

(yes, that's impromptu usage of Leipzig GR . and -)

Yes, I do want to support something like this eventually. (As previously mentioned, it’s important for expressing e.g. tone shift rules.)

What I do miss from about every SCA syntax is specifing the 'next to' sort of conditions. E.g. velars turning into uvulars next to low vowels:

Code: Select all

K → Q / LOW_
K → Q / _LOW

Why not just write that as K → Q / |LOW| ?

Yeah… this is an annoying case. In Brassica you can supply multiple environments, so this is just K / Q / Low _ / _ Low. Beyond this, I think one hits diminishing returns: having dedicated syntax for ‘next to’ would add a lot of complexity for a very minor improvement.

[Zju]

Yeah… this is an annoying case. In Brassica you can supply multiple environments, so this is just K / Q / Low _ / _ Low. Beyond this, I think one hits diminishing returns: having dedicated syntax for ‘next to’ would add a lot of complexity for a very minor improvement.

You could have syntax that is reinterpreted at tokenisation stage for cheap:, e.g. have a rule that transforms K / Q / _ Low _ to K / Q / Low _ / _ Low before actual SC application begins.

[methor]

if a rule acts on all stops plus /s/, you can’t write [+stop s] directly.

Code: Select all

{[+stop], s}

[bradrn]

if a rule acts on all stops plus /s/, you can’t write [+stop s] directly.

Code: Select all

{[+stop], s}

Oh, good to know that this isn’t an issue after all! Still, it’s probably the less significant of the problems I listed — the requirement for every phoneme to have unique feature assignments is much more of a problem in practice.