Towards a common SCA grammar
Towards a common SCA grammar
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?
Self-referential signatures are for people too boring to come up with more interesting alternatives.
Re: Towards a common SCA grammar
The most important part for me is that it runs online; I don't want to download anything.
ìtsanso, God In The Mountain, may our names inspire the deepest feelings of fear in urkos and all his ilk, for we have saved another man from his lies! I welcome back to the feast hall kal, who will never gamble again! May the eleven gods bless him!
kårroť
kårroť
-
- Posts: 769
- Joined: Fri Jul 13, 2018 11:58 pm
Re: Towards a common SCA grammar
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.
Re: Towards a common SCA grammar
I don't see how this is possible or desirable.alice wrote: ↑Mon Oct 01, 2018 5:45 am 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?
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?
Re: Towards a common SCA grammar
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.Salmoneus wrote: ↑Mon Oct 01, 2018 4:25 pmIn 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?
Self-referential signatures are for people too boring to come up with more interesting alternatives.
Re: Towards a common SCA grammar
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 /ŋ/).
Blog: audmanh.wordpress.com
Conlangs: Ronc Tyu • Buruya Nzaysa • Doayâu • Tmaśareʔ
Conlangs: Ronc Tyu • Buruya Nzaysa • Doayâu • Tmaśareʔ
Re: Towards a common SCA grammar
(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?cedh wrote: ↑Tue Oct 02, 2018 3:50 am 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 /ŋ/).
Self-referential signatures are for people too boring to come up with more interesting alternatives.
Re: Towards a common SCA grammar
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.
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.
-
- Posts: 70
- Joined: Mon Jul 09, 2018 6:01 am
Re: Towards a common SCA grammar
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.
High Lulani and its descendants at Tinellb.com.
Re: Towards a common SCA grammar
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.
Yaaludinuya siima d'at yiseka ha wohadetafa gaare.
Ennadinut'a gaare d'ate ha eetatadi siiman.
T'awraa t'awraa t'awraa t'awraa t'awraa t'awraa t'awraa.
Ennadinut'a gaare d'ate ha eetatadi siiman.
T'awraa t'awraa t'awraa t'awraa t'awraa t'awraa t'awraa.
Re: Towards a common SCA grammar
sorry, that remark of mine was overly sharp.
Re: Towards a common SCA grammar
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!)
Re: Towards a common SCA grammar
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.
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.
Re: Towards a common SCA grammar
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).Ælfwine wrote: ↑Thu Oct 04, 2018 12:44 am 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.
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.
Re: Towards a common SCA grammar
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.Salmoneus wrote: ↑Thu Oct 04, 2018 5:58 amPretty 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).Ælfwine wrote: ↑Thu Oct 04, 2018 12:44 am 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.
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.