Conlangjugator

[mèþru]

also sometimes the spelling difference reflects certain morphophonemic or other contexts that block the change

[Salmoneus]

(Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

Alas, the list of all SCAs that have been created is longer than the list of particles in our galaxy...

...while the list of all SCAs regularly used by anyone other than their creator is extremely small. Partly because when these threads pop up, the interested are generally told to either a) read some books on programming to work out how to make the program work on their computer, and/or b) read some books on programming to work out how to use the program. The discussion then devolves into a cluster of programmers talking about programming issues that outsiders can't understand, and people lose interest.


------

regarding string-based SCAs vs featural ones: I just find string-based processes far more intuitive to work with. Everything's visible, in black and white, and you just say what you want to happen, without having to mentally translate everything into features. What's more, ideologically, I prefer a 'thinner' calculus, rather than a metaphysically 'thick' one as found in featural SCAs, in which we have to act as though everything actual is only a representation of the coincidence of numerous invisible real categories. I'm not a platonist in real life, I don't want to have to pretend to be a platonist to derive my conlang!

In more practical terms, I think maybe the clearest objective advantage of strings is that it's easier to be agnostic with strings. I can have my symbols change into transitional symbols that I don't want to have to make up a featural 'reality' for that then becomes irrelevent once the final form has been reached - I can even shunt my symbols through entirely notional transformation sequences that have no 'reality' but just make it easier to conduct other transformations on other symbols without unwanted symbols getting in the way. I can, in chris' example, treat a and b as different for some purposes without having to decide on and remember some specific difference and then if necessary change that difference later on as things develop. And if I want to apply a change to a, b, and q, I can immediately and easily define a new group just for that purpose and never have to worry about it again, and without having it accidentally interfere in other changes.

I suspect strings result in "worse" coding, because they give you more direct control and less need to keep track of things (unless of course you treat 'features' as just an awkward way to define ad hoc groups, in which case you're dealing with strings but in an unnecessarily roundabout way). Certainly the sound change sets I write in zompist's SCA would probably horrify programmers. I suspect featural procedures make it easier to keep things aesthetically neat and concise. But I'm not a programmer, so I don't care (indeed, I actively enjoy chaotic and careless logic, and find neatness of expression offputting).

I tried chris' SCA, and I did indeed find some things easier to do in it than in the SCA. But I also found it constantly counterintuitive and much harder to avoid fatal errors in (which isn't a criticism of chris' implementation, but just the general featural idea). I'm sure, however, that for some people, particularly computer programmers, it's probably the other way around.

[Zju]

I know - I was just listing the people who have participated here so far. I was just surprised that so many people here had made their own. And really, it would be interesting to have some sort of comparison!

Personally I'm not surprised. If you wield a programming hammer, everything looks like a program nail.

it helps to know that, for instance, <tʰ> is related to <t> in a systematic way - which is why I was asking so many questions about phonological models a while ago.

I'm not sure if you're suggesting this, but hardcoding a phonological model is rather restricting - what if a user wants to make a distinction you didn't account for, or has a conlang in which implosives and voiced stops behave the same way?

I mean that they have different semantics. You need to pick one. A good programming or scripting language has simple consistent semantics, but some features naturally fit with a different underlying model of the problem.

The SCA model isn't necessarily either-or. If the program encounters a featureless rule, it could convert the features to segments, apply the rule, and convert everything back to features in the same way it parsed the input. While it's true that working with features is closer to how sound changes work, it has more limited use. Text-based SCA can change spelling to pronunciation, one spelling to another, one writing to another, broad pronunciation to narrow pronunciation, among other things. While it's true these aren't exactly sound changes, they are close in nature and a conlanger is likely to want to make use of them, so it makes sense to have the same grammar and tools for everything.

That's exactly why I keep asking about a Grand Unified Sound Change Applier!

As somebody else already pointed out, this would only lead to xkcd 927. What you can do is define a standard and let developers adhere to it if they will.

Speaking of which, here's a rough draft of a grammar I had in mind for a couple of days. It breaks backward compability and I like semantic versioning, so this calls for v2.0:

More: show

Even you haven't seen a grammar (a set of rules) described in this way, the train of thought is not too hard to follow. In a nutshell each keyword is a set of things, which can replace it and still form a grammatically valid result. ∅ is the empty set (i.e. nothing).

Code: Select all

rules
	rules (new line) sound-change
	rules (new line) directive
	∅

directive
	(the set current set of directives plus maybe some more; not described here)

sound-change
	expression changer expression alternative condition

changer
	>
	->
	→

expression
	expression operator
	∅

alternative //what is the result if the applicability is not met
	| expression
	∅

condition
	/ expression applicability
	∅

applicability
	direction parity
	∅

direction
	"ltr"
	"rtl"

parity
	"even"
	"odd"

operator
	!operator //negative operator, absence of operator
	operator+ //1 or more, matches maximum possible number
	operator? //0 or 1, matches maximum possible number
	operator^ //0 or more, matches maximum possible number
	operator[number - number] //from number to number times
	operator[number] //exactly number times
	(operator) //optional operator
	{operator} //extending scope of outside operators
	number % operator // chance that the operator is taken in consideration
	group
	segment
	_ // all the segments of the input after the match
	# // word boundary
	//maybe also: & (lexeme boundary) $ (syllable boundary)

group
	* //the universal group, contains any and all segments
	[group segment]
	group[list-of-features] //only segments with these features
	group[label] // capturing group, for having segments from groups correspond
	group[!label] // for segments from groups not corresponding
	label
	∅

list-of-features
	list-of-features +feature
	list-of-features -feature
	∅

feature
	label

segment
	label

label
	string character

string
	string character
	∅

character
	(any character that is not reserved nor a number)

number
	0-100 //only in this range
	∅ //unboundness, infinity

Not every operator will be applicable everywhere, but immagine the things you could do with this grammar:

*^ > __ //full reduplication
C^V > __ / #_ //word-initial reduplication
*[-voice] > *[+voice] / V_V //feature-only sound changes
V[-open] > V[+open] / V[+open] //vowel harmony in which open vowels are dominant
V > ə / _C+_ rtl odd //reduce a vowel if it is preceded by the same vowel

Haven't checked if it's mathematically sound!

Wishlist of other features for the next Conlangjugator:
-Grouping of soundchanges with {} so non-linear directives (if, repeat, chance) can act on more than one thing.
-Ability for resegmentation for when orthography changes too much.
-Intermediate forms, just for clarity: in > ĩ > ẽ > e
-Rules that act only in template preview.
-Words being not only strings, but also having information for class, suppletion, principal and irregular forms and then some.

[alice]

(Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

Alas, the list of all SCAs that have been created is longer than the list of particles in our galaxy...

...while the list of all SCAs regularly used by anyone other than their creator is extremely small.

This is the problem. While part of me would welcome an attempt to specify and ultimately implement the One True SCA, I also recognise that not enough people actually use SCA's for standardisation to be really worth the effort. A comparison of the most popular ones would be interesting, if nothing else; more useful would be a survey of who uses which one and why. But, again, do enough people actually use SCA's for this to generate enough useful data?

[Zju]

(Also, so far we have four people in this thread - Zju, chriss_notts, alice and me - who have each made their own SCA. Is there some sort of list of all SCAs currently in existence? It would be really interesting to compare them all!)

Alas, the list of all SCAs that have been created is longer than the list of particles in our galaxy...

...while the list of all SCAs regularly used by anyone other than their creator is extremely small.

This is the problem. While part of me would welcome an attempt to specify and ultimately implement the One True SCA, I also recognise that not enough people actually use SCA's for standardisation to be really worth the effort. A comparison of the most popular ones would be interesting, if nothing else; more useful would be a survey of who uses which one and why. But, again, do enough people actually use SCA's for this to generate enough useful data?

Is there actually any SCA other than both of Zompist's that is used by more than a couple of users?

[Ælfwine]

Honestly, I'd be happy when a sound change applier that adheres to syllabic or stress based developments comes out.

While it can be mimicked, it often creates more problems (and work necessary). For example, if I use a character like (ˈ) then I also have to define when that character causes changes and when it can be ignored.

[bradrn]

Honestly, I'd be happy when a sound change applier that adheres to syllabic or stress based developments comes out.

While it can be mimicked, it often creates more problems (and work necessary). For example, if I use a character like (ˈ) then I also have to define when that character causes changes and when it can be ignored.

I know that my exSCA allows you to use syllable boundaries in sound changes. Basically, you give it a regular expression which matches each syllable; then if you add an x modifier to a sound change, exSCA will insert a user-defined character between each syllable before the change is applied, and will delete it afterwards. (Unfortunately there isn't any 'formal' documentation yet, but at the moment reading the linked thread will give a fairly complete overview of all the features.)

[Ælfwine]

Honestly, I'd be happy when a sound change applier that adheres to syllabic or stress based developments comes out.

While it can be mimicked, it often creates more problems (and work necessary). For example, if I use a character like (ˈ) then I also have to define when that character causes changes and when it can be ignored.

I know that my exSCA allows you to use syllable boundaries in sound changes. Basically, you give it a regular expression which matches each syllable; then if you add an x modifier to a sound change, exSCA will insert a user-defined character between each syllable before the change is applied, and will delete it afterwards. (Unfortunately there isn't any 'formal' documentation yet, but at the moment reading the linked thread will give a fairly complete overview of all the features.)

Cool beans, I'll check it out then.

[Zju]

Update time:

-Improved project documentation. Among other things, it now includes a list and description of the officially supported regex rules.
-Added icons to menus. Menus now also have rounder edges.
-Bug fix: Log can now be cleared.

[bradrn]

Update time:

-Improved project documentation. Among other things, it now includes a list and description of the officially supported regex rules.
-Added icons to menus. Menus now also have rounder edges.
-Bug fix: Log can now be cleared.

This looks much nicer now! I'm particularly impressed with the template system (now that I can figure out how to use it) - it's much nicer than the one in my own SCA.