Re-analysis changes

[edemko]

I was wondering (I've just started playing with this app) if there's a way to re-analyze segments? That is, a given segment might start with one set of features, but then a new generation of speakers would understand that same segment as having different sets of features.

For example, you might have a mid-vowel /e/ split into /e,ɛ/. I thought it might be possible to simply re-define the segment with a Symbol directive as in [1] below, but that's disallowed: "The change rules must come after the symbol declarations".

I'm sure I can workaround this if I need to; I was just surprised by what appears (to me) to be an unnecessary restriction.

---

Example 1:

Feature height(high, mid, low)

Symbol i [high]
Symbol e [mid]
Symbol a [low]

palatalize-1:
  s => ʃ / _ [high]

e-split:
  e => ɛ // _ j

Symbol e [high]
Symbol ɛ [mid]

palatalize-2:
  s => ʃ / _ [high]

With this, you'd have /sa, se, sej, si/ => /sa, sɛ, sej, ʃi/.

For a workaround, I'd probably replace the initial /e/ with the more-cumbersome /e̞/, and then just move the new /e,ɛ/ up to the start. This would be rather less self-documenting, as I'd have to find a superset of the phonemes of all language stages (or be much more phonetic than usual). Alternately (and more relevant to an implementation), I could split the rules across two files, but then it's a bit harder to track the timing of changes.

[def-gthill]

There's currently no way to change declarations partway through the sound changes. In principle this is possible — internally, each rule has its own declarations — but I haven't worked through the implications of exposing this to the user.

Your situation points out one of the reasons I'd be nervous about it: you have the same rule doing two different things depending on where it is in the file.

Is there something stopping you from writing palatalize-2 as s => ʃ / _ {[mid], [high]} instead?

[edemko]

For this minimal(ish) example case, I probably would just write it as you indicated; once I try to put in a full phonology and change it across a few centuries... that's where it's more difficult to refactor the rules.

As for your apprehension, the fact that the same rule can perform two different actions based on its file position is actually why I want this capability. Consider two changes: one affects rhotics (regardless of phonetic detail), while another re-classifies /ɾ/ from a (allophonically reduced) stop to a rhotic. The ordering of these two rules in time will affect the final result, even though the re-analysis step results in no surface-level change.

Perhaps as a compromise, what if there were some obvious "next block" syntax, like ------ that must separate rules from following declarations? The behavior would be like (effectively) splitting the changes into two files and running both.

---

Below, I'm kinda just blabbing, and maybe from within a theory that isn't well-accepted, but it might give some insight into why I'm really seeking this feature out.

Rhotics are kinda notorious for being a phonologically-relevant group with no objective phonetic basis, but various vowel properties are similarly difficult to pin down. Are unrounded vowels in the same front↔back category as their rounded counterparts (for articulatory reasons), or are they considered fronted/backed (for acoustic reasons)? Such questions have consequences that create unusual vowel harmony or gradation systems.

These re-analyses are part of the story of language change, and I'm going to tell that story all the way through. If I can tell that story to a human in a way that my computer will also understand, that would dramatically reduce the manual work I have to do to keep a language family's evolution accurate to my ideas.