Brassica SCA [v0.2.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.