Ketsuban wrote: ↑Fri May 24, 2024 11:24 pm
- 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?