Brassica SCA [v1.0.0]

[bradrn]

Second: Why did you choose to name it Brassica?

Finally, someone asks! Because it’s BRAd’s SCA, of course!

(where SCA = Sound Change Applier)

First: Looks and sounds very useful and interesting!

Thanks!

[Raholeun]

After four years of development, it gives me enormous pleasure to finally announce version 1.0.0 of Brassica! Most of the big changes have been discussed here already, so just go straight to try it out online

The linked page states: "This page runs Brassica 0.3.0". Presumably that is an oversight?

EDIT: I believe the correct link should be https://bradrn.com/brassica/index.html.

[alice]

Many congratulations!

I'm not sure what I did to merit thanks, though!

[Darren]

(Though if I’m not mistaken, braces in square brackets are from 0.2.0. Not sure what the ‘wildcard thingy’ is.)

Haha I guess I just never noticed them. The wildcard thingy is ^.

Oh, interesting idea. I could certainly have a go at making that… after taking a break. I can do no more sound changes for the next little while!

I understand, it must of taken a lot of work to get 1.0.0 up.

putten

This inescapably makes me think of Travis…

I like to slip them in every now and again

[Darren]

After four years of development, it gives me enormous pleasure to finally announce version 1.0.0 of Brassica! Most of the big changes have been discussed here already, so just go straight to try it out online

The linked page states: "This page runs Brassica 0.3.0". Presumably that is an oversight?

That's weird, for me the page says it runs 1.0.0.

[fusijui]

Just popping in to say, congratulations!!!

[bradrn]

After four years of development, it gives me enormous pleasure to finally announce version 1.0.0 of Brassica! Most of the big changes have been discussed here already, so just go straight to try it out online

The linked page states: "This page runs Brassica 0.3.0". Presumably that is an oversight?

EDIT: I believe the correct link should be https://bradrn.com/brassica/index.html.

My guess is browser caching problems. Try force-refreshing if it still doesn’t work. Both those links should point to the same place.

(I did find a typo where it said 0.3.0 where it should be 1.0.0, but that was on the paradigm builder page.)

I'm not sure what I did to merit thanks, though!

As I recall, you helped out with the design of the new feature system.

(Though if I’m not mistaken, braces in square brackets are from 0.2.0. Not sure what the ‘wildcard thingy’ is.)

Haha I guess I just never noticed them. The wildcard thingy is ^.

The wildcard has also been around for some time. (I don’t recall exactly when I added it.)

[Darren]

I guess I never checked the documentation after I learnt how to use it so a few things passed by me. One thing I am sure of is that the new web version scrolls the input and output sections simultaneously which is a nice touch


Is there any way Brassica can apply rules iteratively?

[bradrn]

One thing I am sure of is that the new web version scrolls the input and output sections simultaneously which is a nice touch

That’s been in the desktop version for some time, but v1.0.0 adds it to the web version too. I find it immensely convenient.

(I should mention that there’s a checkbox to disable the behaviour, since occasionally it gets annoying.)

Is there any way Brassica can apply rules iteratively?

As of version 1.0.0: yes, rules are applied iteratively by default! It’s one of the big improvements in this version.

[Darren]

Sorry to ask so many questions brad, but is there a way of simplifying this rule

categories
labial = p b m β
coronal = t d n l
palatal = c j ñ y
velar = k g ŋ w
end

palatal → / _ i
velar → palatal / _ i
coronal → palatal / _ i
labial → velar / _ i

into less than four lines? I feel like backreferences ought to be involvable somehow but I can't get it to work.

[bradrn]

Sorry to ask so many questions brad, but is there a way of simplifying this rule

categories
labial = p b m β
coronal = t d n l
palatal = c j ñ y
velar = k g ŋ w
end

palatal → / _ i
velar → palatal / _ i
coronal → palatal / _ i
labial → velar / _ i

into less than four lines? I feel like backreferences ought to be involvable somehow but I can't get it to work.

Yes, you can do it by combining categories. I’d write it like so:

palatal / / _ i
[labial coronal velar] / [velar palatal palatal] / _ i

Of course, the second rule here only works because all the categories have the same number of elements. Otherwise the left and right sides would expand out to categories of different lengths, and things would become confusing very quickly.

(If you use braces cleverly you can write the whole thing in one line: [labial coronal velar {palatal}] / [velar palatal palatal {}] / _ i. But I think this is needlessly obscure.)

[Darren]

Yes, you can do it by combining categories. I’d write it like so:

palatal / / _ i
[labial coronal velar] / [velar palatal palatal] / _ i

Of course, the second rule here only works because all the categories have the same number of elements. Otherwise the left and right sides would expand out to categories of different lengths, and things would become confusing very quickly.

(If you use braces cleverly you can write the whole thing in one line: [labial coronal velar {palatal}] / [velar palatal palatal {}] / _ i. But I think this is needlessly obscure.)

Ah, of course. I was trying to do [palatal velar coronal labial] → [{} palatal palatal velar] / _ i but obviously that didn't work.

[bradrn]

Yes, you can do it by combining categories. I’d write it like so:

palatal / / _ i
[labial coronal velar] / [velar palatal palatal] / _ i

Of course, the second rule here only works because all the categories have the same number of elements. Otherwise the left and right sides would expand out to categories of different lengths, and things would become confusing very quickly.

(If you use braces cleverly you can write the whole thing in one line: [labial coronal velar {palatal}] / [velar palatal palatal {}] / _ i. But I think this is needlessly obscure.)

Ah, of course. I was trying to do [palatal velar coronal labial] → [{} palatal palatal velar] / _ i but obviously that didn't work.

Ah! That can work, as long as you put braces around the first palatal to make Brassica treat it as a single element.

[Darren]

Ah! That can work, as long as you put braces around the first palatal to make Brassica treat it as a single element.

Good, yeah I get the braces now — what still goes over my head is the austosegments.

(I was going to ask a question about wildcards, but I worked out the problem; wildcards have to be followed by a lexeme, but I wanted to follow one with the environment - something along the lines of a → b / _ # // b ^ _.)

[bradrn]

Ah! That can work, as long as you put braces around the first palatal to make Brassica treat it as a single element.

Good, yeah I get the braces now — what still goes over my head is the austosegments.

What it amounts to is adding a feature declaration (like $Feature) after every autosegmental grapheme. It is confusing, and I apologise for that. The documentation (both for this and for the underlying feature mechanism) went through several rewrites, and I’m still pretty sure I explained it poorly.

(I was going to ask a question about wildcards, but I worked out the problem; wildcards have to be followed by a lexeme, but I wanted to follow one with the environment - something along the lines of a → b / _ # // b ^ _.)

Yes, this is a longstanding annoyance. Unfortunately it’s fairly deeply related to the way the wildcard is implemented (which depends on having a single following element to check against). Perhaps I can rethink this design for v1.1.0.

For now, my best advice is to rewrite it as a right-to-left rule: -rtl a / b / _# // ^b _. (From 1.0.0 this beings its own confusion because it changes the direction of the wildcard syntax, but it does at least work.) Another options is to do b [C V]* _, which is annoying in a different way.

[Darren]

What it amounts to is adding a feature declaration (like $Feature) after every autosegmental grapheme. It is confusing, and I apologise for that. The documentation (both for this and for the underlying feature mechanism) went through several rewrites, and I’m still pretty sure I explained it poorly.

I kinda understand it, but I'm struggling with stopping it from outputting multiple options with changes like w → u / _ C which does things like awta → auta/aúta.

For now, my best advice is to rewrite it as a right-to-left rule: -rtl a / b / _# // ^b _. (From 1.0.0 this beings its own confusion because it changes the direction of the wildcard syntax, but it does at least work.) Another options is to do b [C V]* _, which is annoying in a different way.

Ah, I thought there might be something in the -rtl flag but I didn't work out the syntax right. I could also make another category which contains everything and have // b X* _.

[bradrn]

What it amounts to is adding a feature declaration (like $Feature) after every autosegmental grapheme. It is confusing, and I apologise for that. The documentation (both for this and for the underlying feature mechanism) went through several rewrites, and I’m still pretty sure I explained it poorly.

I kinda understand it, but I'm struggling with stopping it from outputting multiple options with changes like w → u / _ C which does things like awta → auta/aúta.

You can specify ‘⟨u⟩, precisely as written, no special behaviour’ by following it with a tilde: w → u~ / _ C. (I feel sure I did put that in the docs somewhere, though perhaps I forgot.)

For now, my best advice is to rewrite it as a right-to-left rule: -rtl a / b / _# // ^b _. (From 1.0.0 this beings its own confusion because it changes the direction of the wildcard syntax, but it does at least work.) Another options is to do b [C V]* _, which is annoying in a different way.

Ah, I thought there might be something in the -rtl flag but I didn't work out the syntax right. I could also make another category which contains everything and have // b X* _.

Sure, that’s another approach. I’ve considered adding a special character to match any grapheme, but I haven’t been sure how widely useful that would be.

[Darren]

What it amounts to is adding a feature declaration (like $Feature) after every autosegmental grapheme. It is confusing, and I apologise for that. The documentation (both for this and for the underlying feature mechanism) went through several rewrites, and I’m still pretty sure I explained it poorly.

I kinda understand it, but I'm struggling with stopping it from outputting multiple options with changes like w → u / _ C which does things like awta → auta/aúta.

You can specify ‘⟨u⟩, precisely as written, no special behaviour’ by following it with a tilde: w → u~ / _ C. (I feel sure I did put that in the docs somewhere, though perhaps I forgot.)

Oh I see that now. I'm a hella skim reader so it takes like forty goes to get anything into my head

I’ve considered adding a special character to match any grapheme, but I haven’t been sure how widely useful that would be.

Yeah, it would be kinda useful but it's easy enough to define it yourself.

[bradrn]

Oh I see that now. I'm a hella skim reader so it takes like forty goes to get anything into my head

Yep, I have the same problem. I tried to structure the docs nicely and bold the important bits, but it’s hard to do really well.

(If it helps at all, GitHub does generate a table of contents, but the button is non-obvious.)

[Travis B.]

Congratulations! Keep up the good work!

(And yes, I would say "putten" there - lol)