Brassica SCA [v1.0.0]

[dhok]

The readme says "exSCA version 2.1.1"...ah, wait,hmm. You are quite sure I want the online version that says version 0.0.2, not the desktop version linked therein?

No, I’m quite sure you don’t want exSCA at all, because that’s a different SCA. In fact, it’s my old SCA which is now long-deprecated in favour of Brassica. How come you ended up there?

It's linked on the main page for Brassica, which advertises it as supporting multiple features that the online version doesn't have!

[Rounin Ryuuji]

Can the sound change applier be made to apply the steps in a specific order, rather than apparently all at once?

It does apply them in order. Could you supply more details as to your specific problem please?

Oh, I have a change that does /t/ > /s/ before /i/, which works fine; but later a change of /u/ > /y/ in certain circumstances, and a subsequent change of /t/ > /s/ before /y/, but this last one doesn't work.

[bradrn]

The readme says "exSCA version 2.1.1"...ah, wait,hmm. You are quite sure I want the online version that says version 0.0.2, not the desktop version linked therein?

No, I’m quite sure you don’t want exSCA at all, because that’s a different SCA. In fact, it’s my old SCA which is now long-deprecated in favour of Brassica. How come you ended up there?

It's linked on the main page for Brassica …

Sorry, but I can’t any such link. Could you please share a screenshot of where you’re looking, or at least give me a URL?

… which advertises it as supporting multiple features that the online version doesn't have!

This is very fair, though. I really should add a warning that the online version doesn’t support all features. (And find some time to implement the most important ones, too!)

Oh, I have a change that does /t/ > /s/ before /i/, which works fine; but later a change of /u/ > /y/ in certain circumstances, and a subsequent change of /t/ > /s/ before /y/, but this last one doesn't work.

Hmm… could you share the precise rules, please?

[Rounin Ryuuji]

Hmm… could you share the precise rules, please?

I've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].

[dhok]

No, I’m quite sure you don’t want exSCA at all, because that’s a different SCA. In fact, it’s my old SCA which is now long-deprecated in favour of Brassica. How come you ended up there?

It's linked on the main page for Brassica …

Sorry, but I can’t any such link. Could you please share a screenshot of where you’re looking, or at least give me a URL?

It is noted as being downloadable from a Github repository:

[bradrn]

Hmm… could you share the precise rules, please?

I've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].

You have some typos. The last few rules should be:

Code: Select all

ʉ́ᵝ j ʉ̀ᵝ / ýᵝ ì j / _  ; added in spaces
; skip a few...
j / ʎ / _#            ; match at end of word rather than beginning

With the former rule, you accidentally created ýᵝìj as a single multigraph; with the latter, you put the symbols the wrong way around.

It is noted as being downloadable from a Github repository:

[screenshot]

OK, something is going badly wrong here, because for me that links to https://github.com/bradrn/brassica. Moreover, it has linked there ever since I first uploaded it to my webserver. I’m not sure how you got to exSCA from that.

[Rounin Ryuuji]

Hmm… could you share the precise rules, please?

I've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].

You have some typos. The last few rules should be:

Oh, thank you, it works now.

[dhok]

Hmm… could you share the precise rules, please?

I've attached a screencap. Everything but the last two changes seem to work. The fourth item should come out [s̪ýìʎ].

You have some typos. The last few rules should be:

Code: Select all

ʉ́ᵝ j ʉ̀ᵝ / ýᵝ ì j / _  ; added in spaces
; skip a few...
j / ʎ / _#            ; match at end of word rather than beginning

With the former rule, you accidentally created ýᵝìj as a single multigraph; with the latter, you put the symbols the wrong way around.

It is noted as being downloadable from a Github repository:

[screenshot]

OK, something is going badly wrong here, because for me that links to https://github.com/bradrn/brassica. Moreover, it has linked there ever since I first uploaded it to my webserver. I’m not sure how you got to exSCA from that.

Not sure either, but I have downloaded the desktop-side Brassica now. Thanks!

[dhok]

(Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)

[bradrn]

(Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)

Oh, I fully agree. The current font certainly isn’t ideal — its main virtue is that everyone has it installed. A font selector will be added in the next release.

[Rounin Ryuuji]

(Incidentally, I don't want to sound petty--I've been making good use of Brassica and love it to bits--but it would be really useful if there were a way to increase the font size and perhaps even the font. Distinguishing acute accents or weird IPA characters can be rough, especially if you've got a setup with a second monitor; and combining diacritics don't look that great in Courier.)

Oh, I fully agree. The current font certainly isn’t ideal — its main virtue is that everyone has it installed. A font selector will be added in the next release.

That is wonderful of you.

[dhok]

Thanks muchly for the upcoming font selector!

Another idea that occurred to me, since we're basically coding in a bespoke programming language, is the ability to group changes into higher-level blocks that can be toggled off and on. This could eventually be expanded to make it easier to work on families as a group rather than individually. (Though you've probably thought of something like this...)

Let's say I've got a massive family that ranges over 4000 years with a lot of more-or-less binary branching and clades nestled within clades. Then I might write something like

Code: Select all

; changes shared by everyone except branch A
T / D / N_
[k g] / [ts dz] / _[i e]

; except branches A and B
[ɨ ɤ] / [i e]
p / f / _ / N_

; except branch C
θ / f
[k g] / [kʷ gʷ] / _u
u / i

But suppose I'd like to see what Proto-Everyone-But-A looked like--maybe I want to see what sorts of paradigmatic repairs are going to show up in all the downstream clades. I think you might want some sort of syntax like this:

Code: Select all

; changes shared by everyone except branch A
block $alpha on {
    T / D / N_
    [k g] / [ts dz] / _[i e]

    ; except branches A and B
        block $beta on {
            [ɨ ɤ] / [i e]
            p / f / _ / N_

            ; except branch C
            block $gamma on {
                θ / f
                [k g] / [kʷ gʷ] / _u
                u / i
                }
            }
        }

Here, block #beta on could be switched to off--and presto, you're looking at Proto-Everyone-But-A.

At that point maybe it would need to look like a text editor, but perhaps not. Another option, and perhaps a simpler one that requires less programmer-brain, might be to introduce some sort of keyphrase syntax like intermediate[A]. This could signal to the program that it should add an "Apply: A" button under 'Apply' which would apply all rules up to A, but effectively comment out anything that follows. I don't know Haskell and don't know how much of a pain in the rear this would be.

Another option for what this might look like from the user's end that occurs to me is that, just as the user defines categories at the start of the rule file, the user could define rule blocks within the rule file, then specifically tell the program which ones are run. For example, suppose we were making a rule file for the Algonquian languages. We could introduce some keywords: child, inherits and history. Languages that branch off early will just be declared as:

Code: Select all

child ar[Arapaho:on]

This would produce a tag ar that could be used to define a block of changes applying only to Arapaho:

Code: Select all

history(ar)
(R)V // _#
[o ō] / [i ī]
k // _
p / k 
r / n
s / n / #_
history(ar).end

(The on keyword here is very much just a suggestion. The idea is that it would tell the program to create an "Apply (Arapaho)" button under the 'Apply' button. Switching to off would take the button away, if you're working with a large family.)

The keyword inherits could be used to help keep daughter clades in check. For example, all the (non-Blackfoot) Algonquian languages east and south of Arapaho and Cree merge PA *r and *θ, and all of those minus Cheyenne and Menominee also merge *h and *ʔ before a consonant. (While Algonquian doesn't lend itself too well to the tree model, we'll pretend it does for the purposes of what I'm sketching out; we'll name these clades "alpha" and "beta" as a proof of concept.) Then:

Code: Select all

child ar[Arapaho:on]
child cr[Cree:on]
child alpha[Alpha:on]
child ch[Cheyenne:on] inherits alpha
child men[Menominee:on] inherits alpha
child beta[Beta:on] inherits alpha
child mes[Meskwaki:on] inherits beta
child oj[Ojibwe:on] inherits beta

history(alpha)
θ / r
history(alpha).end

history(ch)
[o ō] / [i ī]
[h N] / / _C
; etc. etc.
history(ch).end

history(men)
ʔ / h / _[p k]
š / s
;etc. etc.
history(men).end

history(beta)
ʔ / h / _C
history(beta).end

history(mes)
N / / _C
hr / s
nr / t
history(mes.end)

This would take a bit more finagling with keywords and block declaration, but it would let the user work on a related group of languages as a family and not in isolation, and fits much better with the way historical linguists actually think about sound change in a comparative context.

[bradrn]

Another idea that occurred to me, since we're basically coding in a bespoke programming language, is the ability to group changes into higher-level blocks that can be toggled off and on. This could eventually be expanded to make it easier to work on families as a group rather than individually. (Though you've probably thought of something like this...)

Ooh, I love this idea! Thanks for the suggestion! I’ll definitely have to implement this soon.

[dhok]

IIRC from when I was playing with building desktop-side applications, getting the program to add buttons in real-time is a hassle, so maybe there should be a drop-down menu under or next to the 'Apply' button that has the child tags. You may have intuited that the post I made last night was somewhat stream-of-consciousness, as better ideas for how to handle family-wide diachronics came to mind.

In real life, also, clades are not always entirely clean cuts--consider Aragonese, which is indubitably a Western Romance language about halfway between Catalan and Spanish, but which avoided intervocalic voicing (which the rest of Western Romance underwent). That doesn't mean that it isn't sensible to fit it within Western Romance in the program. Rather, we might write something like this:

Code: Select all

child WR[Western Romance:on]
child IR[Ibero-Romance:on]
child Cat[Catalan:on] inherits(WR)
child Arag[Aragonese:on] inherits(WR IR)
child Port[Portuguese:on] inherits(WR IR)

categories
T = p t k
D = b d g
V = i e ɛ a ɔ o u
;etc.
end

history(WR)
except(Arag): T / D / V_V
except(Port Cat): [ɛ ɔ] / [ie uo]
;etc.
history(WR).end

history(Arag)
uo / ue
lj / ll
;etc.
history(WR).end

I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions. (Although, just as categories form blocks, maybe we'd also need to build children within blocks, as something like this?

Code: Select all

children
child WR[Western Romance:on]
;etc.
children.end

If we use a drop-down menu, maybe the 'on/off' switch on clades is no longer necessary.

But this sort of structure, which allows clades but also exceptions, would essentially smuggle the wave model of sound change into an architecture built on the tree model. To complement the history structure, we might also be interested in creating, effectively, a function constructor, which fires only when called. Suppose we were doing Indo-European and wanted to model laryngeal development. The laryngeals, of course, cheshirized *mostly* the same way everywhere but there were enough edge cases that the results were plenty messy. At the same time, though, we'd prefer not to write almost exactly the same sound changes for every dozen or so branches of IE. So instead, we could do something like this:

Code: Select all

children
child anat(Anatolian)
child core(Core IE)
child gr(Greek) inherits core
child sk(Sanskrit) inherits core
child bt(Baltic) inherits core
children.end

categories
T = p t k ḱ kʷ
D = b d g ǵ gʷ
Dʰ = bʰ dʰ gʰ ǵʰ gʷʰ
Tʰ = pʰ tʰ kʰ ḱʰ kʷʰ
N = m n
R = m n w r l y
H = h₁ h₂ h₃
C = T D Dʰ N R H s
E = e o
Ṛ = ṃ ṇ u ṛ ḷ i
V = E Ṛ a ā ē ō
end

block laryngeals
e / a / h₂_
e / o / h₃_
e / ē / _h₁
e / ā / _h₂
e / ō / _h₃

case(gr)
[h₁ h₂ h₃] / [e a o] / [#C]_[CṚ]
case.end

case(sk)
H / i / C_[C#]
T / Tʰ / _H
case.end

case(bt)
/ h₁ / V_D
[Dʰ] / [D] / _
V / Vˀ / _H[C#]
; where Vˀ has to be defined in or just before history(bt) fires, but this case gets skipped until then
case.end

except(anat): H / / _
laryngeals.end

history(gk)

law: laryngeals
law: centumization
Dʰ / Tʰ
Tʰ / T / _VTʰ

history(gk).end

Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade (or maybe multiple, as case(a b c)), which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)

My presumption is that in the code, clade inheritance and calling a sound law would get treated very similarly, but they're conceptually distinct and distinct enough in reality (tree model vs. wave model) that allowing the user to separate them is probably ideal.

(And yet another addendum...) for a large enough family, this may also imply that we might want to make categories somewhat daughter-specific rather than having a one-size-fits-all structure that has to be reworked for every daughter. Consider a toy family with the vocalic proto-inventory of Finnish: *i *y *e *ø *æ *u *o *ɒ. Daughter 1 is marked by extensive palatalization, and the operative distinction in the vowels is front vs. back; daughter 2 is marked by rounding, and the operative distinction is rounded vs. unrounded. (And I just noticed that if we have a children...children.end block declaration, we can probably kill the 'child' keyword...)

Code: Select all

children
proto(Proto)
alpha(Alpha) inherits proto ;front vs. back
beta(Beta) inherits proto ; rounded vs. unrounded
children.end

categories(proto)
S = p t k
Z = b d g
N = m n
F = s x h
R = w l y
C = S Z N F R
V = i ü e ö æ u o å
categories(proto).end

history(proto)
; allophonic stuff operative in the proto-language that's a pain to write in the input lexicon can go here
history(proto).end

categories(alpha)
Vf = i ü e ö æ
Vb = u o å
C = C tʃ dʒ ts dz š ; some way of appending to an existing category without overwriting it?
categories(alpha).end

history(alpha)
[k g t d s] / [tʃ dʒ ts dz š] / _[Vf]
history(alpha).end

categories(beta)
Vr = ü ö u o å
Vn = i e æ
C = C kʷ gʷ xʷ
categories(beta).end

history(beta)
[k g] / [kʷ gʷ] / _[Vr]
[ü ö] / [i e]
history(beta).end

(Hmm, I should goof around with Haskell...)

[bradrn]

IIRC from when I was playing with building desktop-side applications, getting the program to add buttons in real-time is a hassle, so maybe there should be a drop-down menu under or next to the 'Apply' button that has the child tags.

It shouldn’t be terribly hard… I’m already doing something not too different for the syntax highlighting. Adding and removing buttons certainly is a bit of a pain, but not horribly so.

I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions.

…

Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade, which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)

These ideas seem reasonable, though I’ll have to see how easy they are to implement.

(Hmm, I should goof around with Haskell...)

Indeed you should! It’s a great language, and gives a very interesting perspective on programming too. (Your mental model of it seems a bit off at the moment, though ‘everything is a function’ isn’t such a terribly bad approximation.)

[dhok]

IIRC from when I was playing with building desktop-side applications, getting the program to add buttons in real-time is a hassle, so maybe there should be a drop-down menu under or next to the 'Apply' button that has the child tags.

It shouldn’t be terribly hard… I’m already doing something not too different for the syntax highlighting. Adding and removing buttons certainly is a bit of a pain, but not horribly so.

I assume the program goes in order through the sound change file, so I hope this wouldn't be too complex. When the user selects Aragonese as the daughter to run, the program would also run Western Romance and Ibero-Romance--but then when it hits the except keyword, checks to see if its argument is the selected daughter or one of its super-clades, then skips that rule. From looking at a quick overview of Haskell, my intuition is that this Haskell should be a good language for making this happen, since Aragonese would be a function built from the Western Romance and Ibero-Romance functions.

…

Here the codeword block defines a group of sound laws, which effectively runs as a function, and the codeword law calls that function. Within the function, the except keyword can be used to define exceptions, or case can be used to define a subfunction applying only to a single clade, which you want to be able to do when a daughter-specific change slips into the relative chronology of a wave change. (For the same reason, case should probably be licit in clade histories as well.)

These ideas seem reasonable, though I’ll have to see how easy they are to implement.

Yeah, I am not asking to be in the driver's seat, here--I know I have programmer brain (App Academy accepted me, although I turned them down), but just haven't built much. These are general ideas for tools that it might be useful to have in a future iteration, but only you'll know what works with the code, so I certainly won't complain if things can't make it in or have to be structured in a different manner. I think what I'm trying to reach towards here is a structure that encourages the user to think about *families*, rather than a collection of descendents that develop in vacuums. (Working on families was of course possible with prior SCA's like Haedus or Zomp's, it just involved reusing a lot of changes.)

I am starting to have enough additional ideas that maybe I just need to learn Haskell and write a competitor. Sorry about the stream-of-consciousness posting style; as is so often the case with these things, using a forum post or chat room as a rubber duck is very useful way of refining the idea.

(the idea that just popped up--and I will try my best to shut up now [is there a way to donate to development?]--is to allow absolute chronologies to be defined as well as relative ones. The keyword would be something like year, taking a single integer. A parameter in the options would allow the user to type in an integer representing the terminus. E.g. if we decide that a vowel shift begins in 1500, then we can type year 1500 right before that vowel shift is executed. If we type "1500" into the parameter box and apply sound changes, all sound changes in the history of the language are applied *until* the program hits the 'year 1500' string, which brings the process to an end early. This way, intermediate stages don't require their own clades.)

(sorry sorry I really will shut up now)

[bradrn]

(sorry sorry I really will shut up now)

No, don’t! I like having a list of things to implement! (Can’t promise I’ll get to any of them, though…)

[dhok]

I see there have been updates to the branch on Github--are we getting a desktop release with a font selector soon? Would be really, really useful.

[bradrn]

I see there have been updates to the branch on Github--are we getting a desktop release with a font selector soon? Would be really, really useful.

Yes, indeed we are! As of five days ago, HEAD now contains a font selector. (Not sure when I’ll be ready to make a release, but I’m getting there…)

[bradrn]

Brassica v0.0.3 is now out! Get it from the release page, or try it online at http://bradrn.com/brassica as usual. Release highlights include:

• The online version has been largely brought to parity with the desktop version, and now includes the paradigm builder and live results view, amongst other features
• Brassica can now process MDF dictionary files (as used by tools including SIL Toolbox and Lexique Pro)
• Rules can be marked as sporadic or otherwise nondeterministic, in which case both the result of applying the rule and the result of not applying the rule will be visible
• Three example sound changes are distributed with both the desktop and the web version
• A precompiled binary for Linux is now distributed (currently only the CLI interface, alas)
• The CLI interface has been wholly updated to improve ease of use (especially on Windows)
• Font customisation for both sound changes and words is now allowed in the desktop interface

Amongst other improvements and bugfixes — refer to the release page (linked above) for the full list.

Note there is one minor detail left to resolve: the Brassica API has also been wholly revamped, and is now actually usable for the first time ever, but alas, I do not have the permissions to upload the library to Hackage yet. I will let you know when it is available there.

As for what’s next… well, I’d love to implement dhok’s idea of toggling blocks on and off, but even more than that I want to find a better solution for suprasegmental and autosegmental stuff, because the current ‘features’ system is horribly confusing. I also want to add some way of backreferencing between categories, but that’s less of a priority unless anyone can come up with a sound change which absolutely requires backreferencing to work. (In fact, this goes generally: please send me any sound changes you can’t implement in Brassica if you find any!) That being said, I’m very busy at the moment, and probably won’t be able to get much more work done on Brassica for some time.