Brassica SCA [v1.0.0]

[Lērisama]

I've been playing with it some more and have another feature request: more flexibility in the when conditions. To take the (simplified Yaazhgigzhoomnem?) example in the docs¹, if it had more valency reducers (let's say both el and oosh), I don't think the condition would be writable in the current version. Maybe something like when (ANTIP is null) or when (ANTIP not (1.el 1.oosh)) or something along those lines. Both would probably be useful in different circumstances

¹Reproduced here for ease of not having to go back and forth and people who didn't write the docs having a clue what I'm going on about:

Code: Select all

NEG = () 2.en
ANTIP = () 1.el
2 TA = wim () soo aa
when (ANTIP not 1.el) -2 ABS = zhaa woo yaa
-1 ERG = zh w y

[bradrn]

(simplified Yaazhgigzhoomnem?)

Yes, that’s the one. It’s absolutely awful as a language, but it has a nice simple templatic structure which makes it good for examples. (Well, the ‘nice simple structure’ is precisely the thing makes it such a bad language… no real language is ever that simple.)

[…] if it had more valency reducers (let's say both el and oosh), I don't think the condition would be writable in the current version.

I think that’s quite possible, yes. But just adding and and or connectives should make everything expressible.

[bradrn]

I have found a bug to report in brassica. Multivalent features seem not to word properly with the set operations

[…] I haven’t looked into the &&Str case. I can do so tomorrow.

I have an explanation for this now. (Which I thought I posted already, but clearly didn’t.)

To quote myself from a GitHub issue where someone else reported this same problem:

As for &&Str, that’s not actually a bug: it’s a deliberate design decision. When there’s more than two features, there’s no one obvious way to arrange the features, so you could end up with unpredictable ordering in V. For this reason Brassica only supports the && syntax when there are two categories. (This is documented in the reference.)

[Lērisama]

I have found a bug to report in brassica. Multivalent features seem not to word properly with the set operations

[…] I haven’t looked into the &&Str case. I can do so tomorrow.

I have an explanation for this now. (Which I thought I posted already, but clearly didn’t.)

To quote myself from a GitHub issue where someone else reported this same problem:

As for &&Str, that’s not actually a bug: it’s a deliberate design decision. When there’s more than two features, there’s no one obvious way to arrange the features, so you could end up with unpredictable ordering in V. For this reason Brassica only supports the && syntax when there are two categories. (This is documented in the reference.)

Excellent, thank you. Cpuld you please then remove the (incorrect) comment in the following example from the writing sound changes guide, which states that &&Str would work

Code: Select all

categories
C = m n p t k b d g f s v z r l y w

+Str+None = a e i o u ə ɨ
+Str+Sec  = à è ì ò ù ə̀ ɨ̀
+Str+Pri  = á é í ó ú ? ?

V = +Str+None &+Str+Sec &+Str+Pri
; or V = &&Str - see below
end

-rtl -1 [+Str+None -ə -ɨ] / +Str+Pri
-rtl C* +Str+None C* +Str+None C* / C* +Str+Sec C* +Str+None C* / _ // ^+Str+Pri _

; dukɨtipəta → dùkɨtìpətá
; dukɨtipetə → dukɨ̀tipétə
; dukɨtipətə → dùkɨtípətə

[bradrn]

Oh wow, I hadn’t realised that was there… it’s removed in the latest version of the docs.