Brassica SCA [v1.0.0]

[bradrn]

While trying to implement some new features, I realised I’m confused by this statement:

I always end up having to make a category "X" which is just all the left over shit like ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.

If those graphemes never get used for anything, then why do you need to include them in a category in the first place?

It's the category that never gets used. When rules produce new graphemes, sometimes it doesn't mind but other times it just gives a bunch of question marks.

Hmm… surely it should only give question marks if there’s another category declaration afterwards? That was my intention, at least; if it’s not doing that, there’s a bug.

It's a minor inconvenience at worst.

Sure, but for the next version I’d like to focus on fixing these inconveniences (so I can finally release v1.0).

[Darren]

Hmm… surely it should only give question marks if there’s another category declaration afterwards?

I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.

[bradrn]

Hmm… surely it should only give question marks if there’s another category declaration afterwards?

I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.

As am I, which is why categories … end adds to the existing categories rather than clearing them (which would be new categories … end). I think the documentation is pretty clear on this point, though please let me know if it isn’t.

[Darren]

Hmm… surely it should only give question marks if there’s another category declaration afterwards?

I think you must be right. I guess I'm just too lazy to redefine all the categories at the same time.

As am I, which is why categories … end adds to the existing categories rather than clearing them (which would be new categories … end). I think the documentation is pretty clear on this point, though please let me know if it isn’t.

Hence why I use categories and add a junk category for all the new graphemes I've produced.

[bradrn]

I always end up having to make a category "X" which is just all the left over shit like ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.

Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.

[Darren]

I always end up having to make a category "X" which is just all the left over shit like ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.

Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.

Aye that's great I'll give it a crack today

[bradrn]

I always end up having to make a category "X" which is just all the left over shit like ŋ kʷ pʷ ɨ ˈ θ and never gets used for anything.

Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.

Aye that's great I'll give it a crack today

Note that it’s not released yet!

[Darren]

Development has slowed down a lot, but finally got around to fixing this! In the next release, you’ll be able to write extra ŋ kʷ pʷ ɨ ' θ at the beginning of the file, which will tell Brassica to recognise those multigraphs as ‘extra’ characters throughout all subsequent category redefinitions.

Aye that's great I'll give it a crack today

Note that it’s not released yet!

Ah right guess I'll have to wait

[bradrn]

For reference, this is my list of what to get done for the next release, which with luck could finally get to v1.0.0:

• Figure out some better way of handling stress, tone etc.
• Improve Brassica’s understanding of MDF dictionary files
• Allow display of intermediate results
• Get the CLI closer to feature parity with the GUI
• Improve documentation

And some things which I’ve already implemented:

• extra directive (as just mentioned)
• Up to 10× speed improvement on desktop by parallelisation
• Allow recognising combining diacritics as forming automatic multigraphs
• Wildcards can now occur in the replacement of a rule

[Ketsuban]

I have a couple of questions.

• I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?
• I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).

  [o u] / [ø y] / _ C Frnt
  [i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
  a / [ɛ ɔ] / _ C Open
  V / / _ #

  This results in an ambiguity where it thinks words like tati and tatu could both end up as either tɛt and tɔt, rather than tati becoming tɛt and tatu becoming tɔt. I can fix this by breaking rule 3 into two rules, one for aCi and one for aCu, but that feels wrong. I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1" and then it wouldn't work until I refreshed the browser window. Is there another way to do what I want here that I missed in the documentation?

[Darren]

• I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).

  [o u] / [ø y] / _ C Frnt
  [i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
  a / [ɛ ɔ] / _ C Open
  V / / _ #

  This results in an ambiguity where it thinks words like tati and tatu could both end up as either tɛt and tɔt, rather than tati becoming tɛt and tatu becoming tɔt. I can fix this by breaking rule 3 into two rules, one for aCi and one for aCu, but that feels wrong. I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1" and then it wouldn't work until I refreshed the browser window. Is there another way to do what I want here that I missed in the documentation?

You can fix it with

Code: Select all

a C [i u] / @2 [ɛ ɔ] @1 C @2 [i u]

since that way you're backreferencing a target element. Although that's not really much less complicated than writing out two rules.

[bradrn]

• I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?

I see no reason why not. I’ll add this to the list.

I was trying to implement a toy version of a Northern Vanuatu-style sound change (where unstressed vowels disappear, influencing the vowel in the preceding syllable to massively increase the vowel inventory of a language).

[o u] / [ø y] / _ C Frnt
[i y e ø o u] / [e ø ɛ œ ɔ o] / _ C [V -Open]
a / [ɛ ɔ] / _ C Open
V / / _ #

This results in an ambiguity where it thinks words like tati and tatu could both end up as either tɛt and tɔt, rather than tati becoming tɛt and tatu becoming tɔt. I can fix this by breaking rule 3 into two rules, one for aCi and one for aCu, but that feels wrong.

Darren is correct here: … / … / _ C Open means ‘apply this rule the same way before all open vowels’. To do this in a single rule, you need to put it in the target (so that the replacement can depend on it) and use backreferencing.

I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"

Now this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?

[Ketsuban]

I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"

Now this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?

a / @1 [ɛ ɔ] / _ C @1 Open

[bradrn]

I tried a backreference and I think I managed to crash the parser, since I got "exit with exit code 1"

Now this shouldn’t happen at all: I’ve never managed to crash Brassica. What sound change did you enter that triggered this?

a / @1 [ɛ ɔ] / _ C @1 Open

OK, I can replicate this. This is very bad… I’ll need to look into it.

EDIT: simplified the trigger to a / @1 [ɛ ɔ] / _ [p t] @1 [e i], which is enough to crash it still.

[bradrn]

The bug should be fixed now. (At least in the code; I won’t update the website until the next release.) The problem was that the target @1 [ɛ ɔ] is referring to category 1, but that category doesn’t exist in the target (which just matches a single grapheme). The code shouldn’t crash in that case anyway, but some stupid bad code made it do so.

This reminds me of an idea I had a while ago, which is to add an extra pre-processing step to link up target and replacement categories. (Currently Brassica does this in an ad-hoc way on each rule application.) The benefit would be that it can catch problems like this early, before it’s even tried to run the rule. It could also be useful for things like e.g. the Index Diachronica, where we want to display category information ahead of time. The major disadvantage would be the added complexity, plus the fact that it might make rules slightly less flexible.

[bradrn]

• I don't have a → key on my keyboard, but I do have programming fonts installed which include a -> ligature. Would it be possible to recognise the -> digraph to separate the input and output as well?

I finally got around to implementing this, though again it’s not released yet.

Speaking of which, I should mention my plans for the next couple of releases. Originally my plan was to make the next release v1.0.0, sorting out a bunch of fundamental issues in the process. But we’ve been discussing those, and it seems that it may take a while before I reach a final design. So I think I’ll release v0.3.0 next, focussing on user interface improvements, and then work on v1.0.0 after that. (And then that should finally give us a good foundation to resume work on the Index Diachronica.)

[Man in Space]

Thank you for all your hard work on this resource most valuable.

[bradrn]

Thank you for all your hard work on this resource most valuable.

You’re very welcome!

(Although to be honest, it’s no longer entirely altruism. There’s now a very faint chance that I could parlay this into a PhD opportunity… unlikely, of course, but people are interested in the ID at least.)

[bradrn]

• Allow recognising combining diacritics as forming automatic multigraphs

I’m beginning to question whether this is really as good an idea as I thought. After all, if a combining diacritic forms a valid multigraph, then it should be listed in the categories anyway, and therefore needs no special handling. And if it doesn’t form a valid multigraph, then what business does Brassica have assuming that it does‽

The one case where it could be useful is very quick-and-dirty experimentation where you don’t even want to bother making categories. But how often does that happen, anyway? When I do that, it’s mostly if I’m debugging, or otherwise using Brassica in a way it wasn’t specifically intended for.

Does anyone else have any particular preferences on this?

EDIT: Perusing previous conversations, I see Darren has explicitly mentioned this as an issue:

It's intuitive enough; or at least, it's not counterintuitive – with the guide it's easily usable even for me. I have had trouble getting it to understand non-precomposed characters like <ɛ́ ɔ́ ɑ̃>; it keeps treating the accents separately for some reason.

Given the above logic, I’m curious to know what your specific problem was, and why writing out the categories wasn’t enough to solve it?

[Darren]

Given the above logic, I’m curious to know what your specific problem was, and why writing out the categories wasn’t enough to solve it?

You know what, I can't work out what my problem was. I do remember having to avoid combining diacritics like the plague since they never worked. I'll have a play around with it and see if I can make it happen again.