Featured Sound Change Applier

I've written a Featured Sound Change Applier, based on Geoff's Sound Change Applier, but with feature support.

Improvements

It functions, but has some issues:

Syntax

The syntax is currently not consistent or efficient. The current syntax allows for two types of statements:

1. o = <+back -low -high +ATR -long>
2. -cons ~ <back|high|low|long|ATR>

Definition 1 states that the phoneme /o/ consists of the features delineated on the right. Definition 2 states that anything containing any of the delineated features also has the value -cons.

In a redesign of the syntax to make it more consistent, I would make sure that everything was more strictly defined:

• <> delimits a feature bundle
• the contents of <> are feature definitions separated by a space
• a feature definition consists of a feature name and optionally a sign, the use of each of which follows:
  • +: value of feature is true
  • -: value of feature is false
  • (none): feature exists
  • 0: feature does not exist
• the sign = sets everything on the right as part of the definition of the element on the left
• the sign ~ sets every element on the right to imply the element on the left

One of the effects of removing the categorisational syntax from the Sound Change Applier and adding the feature syntax is that the space that definitions take up in a definition file is a lot longer. That is, instead of making a short list of categories, each containing a [potentially overlapping] subset of the phonemes, one now must list each phoneme separately and define all of its features in one place (excluding the implications discussed earlier).

Following the syntax redesign above, this problem is practically solved, given the wider variety in how to express things. Consider the following examples of the new syntax:

1. 1. o = <+back -low -high +ATR -long>
   2. <+cons> = <0long 0low 0ATR +acons>
2. 1. <-cons> ~ <back><high><low><long><ATR>
   2. <+cons> ~ <+obs><-stop><+son>
   3. <0ATR> ~ <+cons><-cons +long>a
   4. <+back> ~ oua

Examples 1:1, 2:1, and 2:2 are equivalent to the two existing ways to express things. Example 1:2 is a more efficient way to express the implications which would be written in the current syntax as 0long ~ <+cons>, 0low ~ <+cons>, 0ATR ~ <+cons>, and +acons ~ <+cons>. Example 2:3 is similar to 2:1 and 2:2, but allows real feature bundles and not just feature definitions; that is, it's saying that any phoneme which has <+cons> or <-cons +long> or is 'a' must not have the feature <±ATR>. Example 2:4 is equivalent to a phoneme class in the unfeatured Sound Change Applier, and is equivalent in the current version of the Featured Sound Change Applier to defining each phoneme on the right as having the feature on the left (i.e. o = <+back>, etc.).

In summary, the discussed change to the syntax stands to be implemented; this would make the syntax both more consistent and more efficient to use—both things which an end user would benefit from.

Linearity

One of the ideas originally was to be able to redefine the feature set for a given phoneme at different points in the rule file—e.g., between rules. As the program's written now, any redefinition of a phoneme becomes global (i.e., even if it's after all the rules, it'll take effect as if it were before them all), since the file is read before any other processing occurs: all the sound changes and phoneme definitions are defined—separately—program-internally, and only then are rules applied. Since the redefinition of feature sets for phonemes would be so useful, figuring out a way to do this efficiently is part of any plans to improve the system.

Speed

While not entirely evident in the English example provided, the Spanish example really demonstrates the inefficiency of the code. Several of the methods which convert back and forth between phonemes and feature bundles are quite ineffecient—some operate in O(n²) time, some of the slower ones are called repeatedly for basic operations, and one is even recursive. Some simple caching of feature-to-phoneme and phoneme-to-feature operations (with some logic to make sure that if something changes, the cache would be updated) would already begin to speed up the software considerably, but I think some of the methods could use smarter algorithms that were less costly in terms of processor cycles.

In writing the Featured Sound Change Applier, I prototyped the operations I wanted done and coded them with the simplest algorithms I could thing of, in the interest of time and simplicity. Now that everything functions correctly, time should be spent in making more efficient code.

Dealing with more types of rules

There are two important types of SPE rules which aren't dealt with by the Featured Sound Change Applier: rules involving syllables (1), and rules involving what I'll tentatively call "feature sharing" (2). A typical example of each of these types of rules follows:

1. C_{[+alveolar,+stop]} → ɾ / σ_[+stress] _
2. C → [αvoice] / _ C_α

To implement these additional varieties of SPE-type rules, an extension to the Featured Sound Change Applier's syntax would have to be developed and then implemented in the code.