Towards a common SCA grammar

[alice]

The Ultimate Sound Change Applier is a very difficult thing to define clearly, in part because people all want it to do different things: generate tables of inflectional paradigms, derive an entire child vocabulary, verify that one's child vocabulary is consistent with the sound changes, etcetera. However, it shouldn't be too difficult to decide on a definitive (or ANSI standard) format for the specification of the sound changes themselves. Is there much scope for a debate about this, assuming enough people care?

[mèþru]

The most important part for me is that it runs online; I don't want to download anything.

[akam chinjir]

My wishlist for an Ultimate SCA (naturally I'm in the process of rolling my own) makes some non-trivial demands of the rule parser, especially involving the use of features (including syllable- and word-level features, and features on the right hand side of a rule) and conditions (ones that go beyond just specifying an environment). So for me at least it doesn't make sense to expect different SCAs with different goals to nonetheless be able to work with the same rules.

[Salmoneus]

The Ultimate Sound Change Applier is a very difficult thing to define clearly, in part because people all want it to do different things: generate tables of inflectional paradigms, derive an entire child vocabulary, verify that one's child vocabulary is consistent with the sound changes, etcetera. However, it shouldn't be too difficult to decide on a definitive (or ANSI standard) format for the specification of the sound changes themselves. Is there much scope for a debate about this, assuming enough people care?

I don't see how this is possible or desirable.

Different people will find it easier to use different sorts of grammar. For instance, a feature-based SCA is not going to express its rules the same way as a basic rule/class-based SCA; but some people will prefer one and some will prefer another. The input mechanism will also change things. For instance, if you enter your rules into a premade table, it might be nice to have really clear, unambiguous symbols making it obvious which box does which, like arrows and propositional calculus signs; but if you're having to enter all your rules by hand it's more important to use symbols, like '/', which are easy to enter and edit. [for instance, I find the fact that both dividers in Zompist's SCA are '/' convenient when copy-pasting and editing rules].

In any case, it doesn't make much sense - nor is it likely to happen - to force users of existing SCAs to relearn the entire syntax to suit your preferences. What's in it for, say, Zompist to alienate his userbase by changing his rules to match the rules of your favourite SCA?

[alice]

In any case, it doesn't make much sense - nor is it likely to happen - to force users of existing SCAs to relearn the entire syntax to suit your preferences. What's in it for, say, Zompist to alienate his userbase by changing his rules to match the rules of your favourite SCA?

The answer is clearly "no", then, and this is probably the best reason why. Perhaps if there were enough users of SCAs who were confused by numerous incompatible syntaxes... but this is clearly not the case. So that's one more item to cross off my "Things Which Must Be Done Before I Die" list.

[cedh]

I'm still using v0.5 of your own GSCA, and the things I like most about it compared to other sound change appliers include both the whitespace-based syntax (because it's visually much clearer than e.g. A/B/C_D, especially with tab sizes of 10 or more characters) and the ability to define all phoneme classes on the fly without having to resort to features (<+mnŋbdɡ> is much more concise than anything like {[+nasal] OR [+plosive,+voiced]}, it doesn't involve the additional logical complexities of the latter, and it's even easier to debug because it allows you to search the whole sc file e.g. for "ŋ" to find all changes that involve /ŋ/).

[alice]

I'm still using v0.5 of your own GSCA, and the things I like most about it compared to other sound change appliers include both the whitespace-based syntax (because it's visually much clearer than e.g. A/B/C_D, especially with tab sizes of 10 or more characters) and the ability to define all phoneme classes on the fly without having to resort to features (<+mnŋbdɡ> is much more concise than anything like {[+nasal] OR [+plosive,+voiced]}, it doesn't involve the additional logical complexities of the latter, and it's even easier to debug because it allows you to search the whole sc file e.g. for "ŋ" to find all changes that involve /ŋ/).

(glows with pride) Now, is anybody prepared to explain why each of these things is actually a serious design flaw which renders the thing completely unusable?

[Salmoneus]

Well that got weirdly passive aggressive quickly.

My not using your SCA is not part of some conspiracy or an expression of undying hatred for its 'unusable' features. I don't use it because there's another, more available SCA that I'm already used to, and I'd forgotten you had made one. I suspect the same is true of many other people.

[Ryan of Tinellb]

I wasn't even aware there were this many SCAs. I've played with Zompist's SCA2 in the past, but when it came time to evolve High Lulani into Vulgar, I hardcoded the rules in the Python program I use for all my conlanging.

[Travis B.]

I prefer not to use SCAs but rather to simply apply sound changes from memory. In the case of some of my languages, such as the Tshyak languages, the phonologies are manageable for me without needing an SCA. In the Laqar languages, on the other hand, there is quite elaborate sound change, but using an SCA is prevented by that the phonologies are heavily stress-and-metric-based, and most SCAs to my knowledge have poor support for managing stress and metric structure of words.

[Salmoneus]

sorry, that remark of mine was overly sharp.

[dewrad]

Personally, I always used IPA Zounds, as it was the only program that handled unicode out of the box well at the time, and it dealt elegantly with supersegmentals like stress. Unfortunately, I lost touch with the developer and it didn’t port well to a Mac. Zomp released SCA2 at about the same time, and the handling of digraphs (and thus meaningful category names) as well as a user-friendly GUI sold it for me. I resent command-line only programs, or programs I have to dick around with python, ruby or any other kind of coder shit. Handling stress-conditioned soundchanges was a bit of an issue to begin with, but I soon found reasonable workarounds (I am a total fag for stress-based soundchanges. Stress-conditioned apophony all the way!)

[Ælfwine]

My current pet project is trying to see if I can input all the sound changes from Proto Norse to Old Norse into the SCA2. I find umlaut to be a bit difficult to input. What do you guys use to get around it?

Edit: after playing around with it, it seems like a>b/_(C)(C)c seemed to work, whereas c is the umlauting vowel, a is the vowel being affected and b is the result.

[Salmoneus]

My current pet project is trying to see if I can input all the sound changes from Proto Norse to Old Norse into the SCA2. I find umlaut to be a bit difficult to input. What do you guys use to get around it?

Edit: after playing around with it, it seems like a>b/_(C)(C)c seemed to work, whereas c is the umlauting vowel, a is the vowel being affected and b is the result.

Pretty much, yes. Which you can streamline by making it A/B/_(C)(C)(C)(C)U, where A and B are before and after classes for umlaut, and U is the class of umlauting things, and the extra Cs are because I'm paranoid (and in practice I might well make a bunch of them because I'm also paranoid about brackets, which occasionally seem not to work properly, although it's probably just because i've made errors somewhere).

As someone who recently encoded sound changes similar to those between germanic and middle english: tell me about it. Umlaut. Stress-conditioned changes. High vowel loss in the correct order depending on the weight of preceding syllables. Trisyllabic laxing (or something similar). Ugh.


If you really get into trouble, you can turn to the ellipsis. This lets you do thing like trisyllabic laxing, or umlaut at a distance unless blocked by a back vowel, and stuff like that.

[Ælfwine]

My current pet project is trying to see if I can input all the sound changes from Proto Norse to Old Norse into the SCA2. I find umlaut to be a bit difficult to input. What do you guys use to get around it?

Edit: after playing around with it, it seems like a>b/_(C)(C)c seemed to work, whereas c is the umlauting vowel, a is the vowel being affected and b is the result.

Pretty much, yes. Which you can streamline by making it A/B/_(C)(C)(C)(C)U, where A and B are before and after classes for umlaut, and U is the class of umlauting things, and the extra Cs are because I'm paranoid (and in practice I might well make a bunch of them because I'm also paranoid about brackets, which occasionally seem not to work properly, although it's probably just because i've made errors somewhere).

As someone who recently encoded sound changes similar to those between germanic and middle english: tell me about it. Umlaut. Stress-conditioned changes. High vowel loss in the correct order depending on the weight of preceding syllables. Trisyllabic laxing (or something similar). Ugh.


If you really get into trouble, you can turn to the ellipsis. This lets you do thing like trisyllabic laxing, or umlaut at a distance unless blocked by a back vowel, and stuff like that.

I ran into a similar problem with the word *melukiz where the u blocked the umlaut of i. The ellipsis seems to fix that, but I had difficulties with it in the past, so I'm hesitant to use it.