Zompist Bboard Again

Darren wrote: ↑Tue Jul 16, 2024 4:46 am

bradrn wrote: ↑Mon Jul 15, 2024 5:48 pm 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.

That would be very helpful, thanks!

Darren wrote: ↑Tue Jul 16, 2024 4:46 am 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.

Have you gotten any chance to look at this yet, by some miracle? If not, I’m going to push these changes back to to the release after this next one (which for various reasons I’d like to get out as quickly as possible).

bradrn wrote: ↑Thu Jul 18, 2024 5:47 pm

Darren wrote: ↑Tue Jul 16, 2024 4:46 am 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.

Have you gotten any chance to look at this yet, by some miracle? If not, I’m going to push these changes back to to the release after this next one (which for various reasons I’d like to get out as quickly as possible).

I've found something that, if it isn't actually the it, must be related to my original problem. I stick in these rules:

categories

C = p t k b d g m n ŋ
N = m n ŋ
V0 = i u e o a
Vi = i y ɪ ø æ
Vu = y u ø ʊ ɔ
Va = ɪ ø ɛ ɔ a
V = i y u ɪ e ø o ɛ ɔ æ a
Vnas = ĩ ỹ ũ ɪ̃ ẽ ø̃ õ ɛ̃ ɔ̃ æ̃ ã
R = w l y

end

V0 → Vi / _ (N) C i
V0 → Vu / _ (N) C u
V0 → Va / _ (N) C a
V N → Vnas / _ [C #]
[m n ŋ] → [w l y] / _ Vnas
→ y / [V Vnas] _ [V Vnas]

All well and good; so we get e.g. pibaŋ → pɪbã, godiŋaniŋ → gødiŋælĩ, but then there's also niŋŋaŋ → ?lɪ̃yyã

niŋŋaŋ → nɪŋŋaŋ (V0 → Va / _ (N) C a)
→ nɪ̃ŋã (V N → Vnas / _ [C #])
→ lɪ̃yã ([m n ŋ] → [w l y] / _ Vnas)
→ lɪ̃yyã (→ y / [V Vnas] _ [V Vnas])

For some reason it thinks that either lɪ̃_yã or lɪ̃y_ã is "[V Vnas] _ [V Vnas]"

Darren wrote: ↑Fri Jul 19, 2024 3:08 am For some reason it thinks that either lɪ̃_yã or lɪ̃y_ã is "[V Vnas] _ [V Vnas]"

Indeed it does, because you’ve listed y in the vowels!

V = i y u ɪ e ø o ɛ ɔ æ a

(As an aside, the latest unreleased version of Brassica produces lɪ̃yyyã, because it’s better at applying rules in overlapping environments, and it can see that the rule can apply on both sides of the y.)

bradrn wrote: ↑Fri Jul 19, 2024 4:09 am

Darren wrote: ↑Fri Jul 19, 2024 3:08 am For some reason it thinks that either lɪ̃_yã or lɪ̃y_ã is "[V Vnas] _ [V Vnas]"

Indeed it does, because you’ve listed y in the vowels!

Oh yeah lmao that makes sese

I still can't work out what the origibal problem was (there definitely was one though,

Also (a minor complaint) when you put non-precomposed characters in the rules section, they appear visually as theyre suposed to, but the cursor position treats them as separate spaces, so if you put your cursor in front of one and try and delete it, you'll delete something entirely unrelated. (might just be a problem with the online verison being online (also on a mac if that has nay relevance

Darren wrote: ↑Fri Jul 19, 2024 6:35 am I still can't work out what the origibal problem was (there definitely was one though,

Hmm, OK. For now I’ll leave this behaviour as is, but if you can re-find the problem I’ll fix it in the subsequent release.

Darren wrote: ↑Fri Jul 19, 2024 6:44 am Also (a minor complaint) when you put non-precomposed characters in the rules section, they appear visually as theyre suposed to, but the cursor position treats them as separate spaces, so if you put your cursor in front of one and try and delete it, you'll delete something entirely unrelated. (might just be a problem with the online verison being online (also on a mac if that has nay relevance

Just tested this on my phone (running Safari), and I can confirm the problem. I think this is a bug in the underlying editor component Brassica relies on, but I’ll see if there’s any workaround.

bradrn wrote: ↑Fri Jul 19, 2024 6:55 am

Darren wrote: ↑Fri Jul 19, 2024 6:44 am Also (a minor complaint) when you put non-precomposed characters in the rules section, they appear visually as theyre suposed to, but the cursor position treats them as separate spaces, so if you put your cursor in front of one and try and delete it, you'll delete something entirely unrelated. (might just be a problem with the online verison being online (also on a mac if that has nay relevance

Just tested this on my phone (running Safari), and I can confirm the problem. I think this is a bug in the underlying editor component Brassica relies on, but I’ll see if there’s any workaround.

Yep, this is a bug in the underlying editor, previously reported at https://github.com/ajaxorg/ace/issues/1531 and https://github.com/ajaxorg/ace/issues/5431. I’ve made a post to the latter to see if someone involved in the project can have a look at fixing it, but I don’t have high hopes. If this persists I’ll look into switching to a different editor.

I am glad to announce the release of Brassica v0.3.0! As always, you can try it online or get the desktop version.

The most important changes have already been mentioned earlier in this thread; for more, consult the release highlights.

I will preface this by saying that I am a bit of a midwit and in general Brassica seems to work more intuitively than other SCA's, but I feel that implementing controlling rules and exceptions is a bit tricky. Perhaps the section on "Controlling rule application" in the documentation would benefit from some extra examples.

Raholeun wrote: ↑Tue Jul 23, 2024 5:13 pm I feel that implementing controlling rules and exceptions is a bit tricky

Could you give any specific examples?

Perhaps the section on "Controlling rule application" in the documentation would benefit from some extra examples.

Good to know — I’m planning to completely rewrite the documentation for the next version. (My current plan is to divide it into a quick tutorial-style guide, and a more comprehensive reference guide.)

Perhaps you can only program exceptions that apply to the environment, and not to the target?
Over all the documentation is pretty practical, but here and there it introduces and illustrates a new concept by means of an advanced example. For instance, the exceptions are introduced and in the accompanying example the exception is applied to gemination. But gemination is in itself already more of an advanced rule to learn. That might be too ambitious for less savvy users.

Raholeun wrote: ↑Wed Jul 24, 2024 3:09 am Perhaps you can only program exceptions that apply to the environment, and not to the target?

Code: Select all

; # With the exception of postvelars, all word final consonants are elided
; so that  *-al, *-ak, *-aʕ → -a, -a, -aʕ
 C / / _ # / / Pvel
 

Two things immediately wrong here:

• You’ve got a space between the slashes. The exception is separated by two slashes without spaces, //. (Single slashes separate multiple environments.)
• The exception uses the same syntax as the environment, with an underscore.

That second point implies that the exception is about stuff before and after the target, not about the target itself. If you want to change the target, just, well, change the target: your rule would be [C -Pvel] / / _#.

(It would be interesting to have a more general way of negating whole targets, but I’m just not sure how useful it would be…)

Over all the documentation is pretty practical, but here and there it introduces and illustrates a new concept by means of an advanced example. For instance, the exceptions are introduced and in the accompanying example the exception is applied to gemination. But gemination is in itself already more of an advanced rule to learn. That might be too ambitious for less savvy users.

This is helpful, thanks! I’ll think more carefully about the examples I use next time.

Thanks for the help. One additional thing; in the "Middle to Modern English" preset there's a commented remark at the end that states: But would there not be a way to solve this through the Paradigm Builder? If so, it would be a missed opportunity not to mention this in the preset examples.

Raholeun wrote: ↑Wed Jul 24, 2024 5:24 am Thanks for the help. One additional thing; in the "Middle to Modern English" preset there's a commented remark at the end that states:

Code: Select all

; by this point final -n has long disappeared; 
; this is an inflectional change, which Brassica
; cannot simulate, so the only alternative is to
; make this yet another sporadic change

But would there not be a way to solve this through the Paradigm Builder? If so, it would be a missed opportunity not to mention this in the preset examples.

No, there's not - but the comment could be clearer. What I mean here is that the infinitive ending changed from -n to null, but no other final -n was deleted. Brassica cannot know which -ns come from the infinitive ending and which don't, so it just produces both alternatives. The Paradigm Builder won't help with this problem because it's for building up paradigms from morphemes, not for simulating changes in existing words.

(Admittedly, it would be very nice to have some way to simulate inflectional changes. But how that could work, I'm really not sure...)

Again using Brassica to perform some laborious task. This time, the conditions for metathesis is giving me headaches. There is the following rule: Would you know where I am straying here?

Raholeun wrote: ↑Wed Aug 07, 2024 12:05 pm Again using Brassica to perform some laborious task. This time, the conditions for metathesis is giving me headaches. There is the following rule:

Code: Select all

; Fricatives and approximants metathesize to onset: CV{F/A}(V) -> C{F/A}V(V)
[Fric Aprx] VAll / \ C V _ 

Would you know where I am straying here?

This rule seems syntactically incorrect, from what I can see — why do you have an underscore in the replacement?

Instead, I would write this as:

V [Fric Approx] / \ / C _

That is, a vowel and a fricative/approximant metathesises after a consonant (and before an optional vowel, but because it’s optional, presumably I don’t need to actually specify that).

I will admit that \ is the least useful out of all the various elements supported by Brassica. It only really makes sense when used alone in the replacement, and is only useful for very specific sound changes. Really the only reason it exists is because it was already present in zompist’s SCA². I’m in the middle of a big documentation rewrite which should clarify its behaviour a bit, but I’ve considered deprecating it entirely given the confusion it could cause.

Thanks for the help again, bradrn. There's no time to check the change now, but will do so when I get home from work. And good to hear you are working on the rewrite. If you need a constructive opinion on the revamped documentation, I'm glad to help.

Also, I was looking for an option that lets me define and "print" various stages of the language. Currently, Brassica can show the word input and the output in the results column. There is also the option to list the changes a word has gone through. However, it might be useful to have a keyword that you can insert in the list of rules that causes the words at that stage of the language to be displayed. For example:

kasin → kaʃin → kəʃin → kəʃɛɪ̯n
barin →barin → bərin → bərɛɪ̯n

Raholeun wrote: ↑Thu Aug 08, 2024 2:10 am If you need a constructive opinion on the revamped documentation, I'm glad to help.

Thanks! I was planning to post it here anyway for feedback.

Also, I was looking for an option that lets me define and "print" various stages of the language. Currently, Brassica can show the word input and the output in the results column. There is also the option to list the changes a word has gone through. However, it might be useful to have a keyword that you can insert in the list of rules that causes the words at that stage of the language to be displayed. For example:

kasin → kaʃin → kəʃin → kəʃɛɪ̯n
barin →barin → bərin → bərɛɪ̯n

You’re in luck — I implemented this just yesterday! It should make it into the next release.

Raholeun sent me a couple of questions via PM, but I’m going to answer them here in case they help anyone else:

I want to innovate long vowels, from V1V2 series so that *paen becomes /peen/ and *liu becomes /luu/. That is, the first vowel in a series of two becomes assimilates completely to the following vowel. I have tried things like:

Code: Select all

 V @2V / @1V @1V
 @1V V / @1V @1V 

Evidently to no avail. Getting that line to work would be a great stepforward.

Both lines here have backreferences from a category to itself. Instead try:

V V / @2 V >

That is, ‘copy the second vowel to the output, then geminate it’.

(Equivalently, one could write in the target, @2 V @2 V or ~ V > or so on. But I think the above is clearest.)

The next step would be to state an exception, namely that if the first vowel of the sequence is [V +High] or [V +Low], then that one is leading and doubles, rather than the second one. Easy, right?

Probably best to do this one in three rules:

[V +High] V / [V +High] >
[V +Low] V / [V +Low] >
[V -High -Low] V / @2 V >

(If you really wanted to, you could cram those first two lines into a single rule using nested categories, but then it becomes unreadable.)

The third line here can actually be simplified to V V / @2 V >, because it doesn’t matter if it applies to the output of the first two lines. But I prefer to explicitly specify that it only applies to cases not covered by the first two lines.

Now that I think of it, it would be nice to have a mechanism to say, ‘iterate through a list of targets and match the first one’. IIRC, Lexurgy already has this. I think Brassica could do it by co-opting the category mechanism, which would be less readable but more consistent and compact.

Perhaps more pressingly, I found that I had a hard time coming to grips with the section on categories and features. Let's say that initially one states:

Code: Select all

feature Unassigned = a i u / High = á í ú / Low = à ì ù / Mid = ā ī ū
V = a i u

Later in the language, this vowel inventory is expanded greatly to the 5 cardinal vowels, both long and short, all with nasalized counterparts and several tones. Is it then advised to state the categories again all over? And then, what would be the most econimical way to do this?

Yes: make a new categories block and re-state everything from the beginning, would be my advice. I would not advise experimenting overmuch with the fragile and irritating features system, to which I am desperately trying to find a replacement.