Brassica SCA [v1.0.0]

[Lērisama]

Oh yes, we had to switch off our power for a bit. I’ve restarted the webserver — try again now?

Thank you, it works perfectly now

[Neonnaut]

Brassica 'suffers' from a feature of combining diacritics that I've pointed out with Lexifer.

If I have the rule

Code: Select all

o /

and the words

Code: Select all

xo xȍ

I get the results

Code: Select all

x x̏

instead of the results you might expect, i.e:

Code: Select all

xő x

('o' is matching to the 'o' in 'o' + ◌̏ and leaving the ◌̏ to join onto x).

The workaround in Lexifer is to say in the rule

Code: Select all

filter: o(?=\w|$) > ! 

which produces said expected results. But how would you solve this in Brassica?

[Lērisama]

The workaround in Lexifer is to say in the rule

Code: Select all

filter: o(?=\w|$) > ! 

which produces said expected results. But how would you solve this in Brassica?

You use Brassica's multigraph support. In the initial categories block, you would have a statement like this

Code: Select all

categories
C = p t k m n ng f s x l r
V = a e i o u
V̏ = ȁ ȅ ȉ ȍ ȕ
end

o /
ng / ŋ

As long as any diagraph, including combining diacritics is included in the first category block, it will be treated as one grapheme. See also the ng example. The code above would give the following output:

Code: Select all

xo → x
xȍ → xȍ
xong → xŋ
xȍng → xȍŋ

You can also at any pont include a rule such as the following at any point in the sound changes, even without predefinition of the multigraph

Code: Select all

o ̏ / ȍ ;Makes all cases of o followed by  ̏ be treated as a unitary grapheme
o / ȍ / x _ ;All cases of o become ȍ if they follow an x

[bradrn]

What Lērisama said is correct. You can also avoid a category block by writing the rule manually [EDIT just noticed Lērisama mentioned this too]:

Code: Select all

o ́ / ó

(Where there’s a space between the characters on the left-hand side.)

In the past I’ve contemplated allowing Brassica to automatically create multigraphs from combining diacritics. But this solution is more general, and for any ordinary usecase should work without problems (because everything would usually be listed in the categories block anyway).

[Travis B.]

What Lērisama said is correct. You can also avoid a category block by writing the rule manually [EDIT just noticed Lērisama mentioned this too]:

Code: Select all

o ́ / ó

(Where there’s a space between the characters on the left-hand side.)

In the past I’ve contemplated allowing Brassica to automatically create multigraphs from combining diacritics. But this solution is more general, and for any ordinary usecase should work without problems (because everything would usually be listed in the categories block anyway).

It would be hard to make it robust unless you used a Unicode character library that covered all of Unicode to determine what is and what isn't a combining diacritic.

[bradrn]

What Lērisama said is correct. You can also avoid a category block by writing the rule manually [EDIT just noticed Lērisama mentioned this too]:

Code: Select all

o ́ / ó

(Where there’s a space between the characters on the left-hand side.)

In the past I’ve contemplated allowing Brassica to automatically create multigraphs from combining diacritics. But this solution is more general, and for any ordinary usecase should work without problems (because everything would usually be listed in the categories block anyway).

It would be hard to make it robust unless you used a Unicode character library that covered all of Unicode to determine what is and what isn't a combining diacritic.

Luckily, Haskell has such a function! (In the base library, no less.)

[Travis B.]

Luckily, Haskell has such a function! (In the base library, no less.)

I suspected it might have such a thing.

[Darren]

She's down again I'm afraid.

[bradrn]

She's down again I'm afraid.

I’m not sure why it shut down this time. As far as I’m aware, we did not turn off the power today. I booted up again, so try now.

[Lērisama]

She's down again I'm afraid.

I’m not sure why it shut down this time. As far as I’m aware, we did not turn off the power today. I booted up again, so try now.

It works for me, but I don't know if it was ever down for me, as I didn't test it then

[bradrn]

She's down again I'm afraid.

I’m not sure why it shut down this time. As far as I’m aware, we did not turn off the power today. I booted up again, so try now.

It works for me, but I don't know if it was ever down for me, as I didn't test it then

Well, when I checked the box it was turned off, so it must have been down…

[Darren]

Yes, it's back.

[Man in Space]

It's down again. If it does load, the font's all wrong and you can't open or type anything.

[bradrn]

It's down again. If it does load, the font's all wrong and you can't open or type anything.

Looks like the server got shut down again, so I booted it back up. Looks like it’s working now.

(I don’t know about the fonts and other issues.)

[Man in Space]

Looks like it’s working now.

Thank you!

(I don’t know about the fonts and other issues.)

I think it was a cacheing issue on my side of the screen.

[Lērisama]

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

When I checked this example from the writing sound changes guide

Code: Select all

extra . ;I added this to show the problem; it shouldn't effect V
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

. / V ;Check what the vowels are

And I get the output à/è/ì/ò/ù/ə̀/ɨ̀/á/é/í/ó/ú/?

If I swap the V definition for

Code: Select all

V = &+Str+None &+Str+Sec &+Str+Pri

I get the correct a/e/i/o/u/ə/ɨ/à/è/ì/ò/ù/ə̀/ɨ̀/á/é/í/ó/ú/?

Using the

Code: Select all

V = &&Str

Option is even worse. I get the result &Str

I have no idea what is going on here, but something is clearly going wrong

---

In somewhat happier news, I got round to trying the paradigm builder. I really like it; very useful in developing paradigms¹. There does seem to be a small bug where line breaks are treated as a signal to stop, even if there are more lines with stuff in below, but other than that, I really like it. I do have feature requests though:

Firstly, and most simply², I'd appreciate being able to be able to select whether one of a set of features are present, so if I write something like

Code: Select all

NOM ACC GEN
SG PL
(NOM or ACC) PL > 1.i
GEN PL > 1.o
GEN SG > 1.a
ACC > 2.s
GEN > 2.n

I'd get
test testi
tests testis
testan teston

Secondly, I'd like to be able to combine sound changes with the paradigm builder without having to copy-paste. When I was working out the subject/tense agreement for my new conlang, working out both the paradigm and the brassica to get the surface forms³ at the same time was a pain, especially when I was testing how various changes to the paradigm would interact with various changes to epenthesis rules – it got quite tedious. Ideally I'd be able to do something like⁴:

Code: Select all

paradigm
TNS = PRS PST
AGR = fst snd trd nprs
when (AGR not nprs) NUM = SG PL
PST SG > -1.j
PST PL > -1.h
PST fst SG > 1.i
PSR snd SG > 1.i
PRS fst PL > 1.h
PRS snd PL > 1.n
fst SG > 2.θ
snd SG > 2.n
PRS trd SG > 2.i
fst PL > 2.te
snd PL > 2.ne
PRS trd PL > 2.tti
PST trd PL > 2.ʔ
nprs PRS > (-1.na 2.í)
nprs PST > (-1.nj 2.h)
end
; Various brassica stuff here

At the start of a set of sound changes.

Lastly, I'd like the ability to select between different stems for a word. To use a conlang example again, LZ uses many different ways of forming two different stems for the (im)perfective, adding one of a variety of affixes to one of the forms, or using suppletion, and it would be nice to be able to use something like

Code: Select all

;In the roots
a ēk a
āg āziv āz
pulrĭ pul pul

; In the paradigm definition
ASP = NPF PRF SUP
NPF > 0.#1
PRF > 0.#2
SUP > 0.#3 1.i
when (ASP not SUP) 1 AGR = a r h ān ās āh

and get
aa ar ah aān aās aāh
ēka ēkr ēkh ēkān ēkās ēkāh
ai

āga āgr āgh āgān āgās āgāh
āziva āzivr āzivh āzivān āzivās āzivāh
āzi

pulrĭa pulrĭr pulrĭh pulrĭān pulrĭās pulrĭāh
pula pulr pulh pulān pulās pulāh
puli

Sorry for bringing up so many things at once, but I did notice them pretty much at the same time

¹ Shocking, I know. It was never designed for such a use
² And also most pointlessly, since it doesn't add any new functionality, just saves some rule writing
³ There is a lot of cluster & hiatus resolution in this conlang
⁴ Yes this is the real rules for the (what I've done so far) of the verbs for this conlang. The nicest class of verbs comes out as:
ipáθ ipáhte
ipán ipánne
ipáyi ipáčči
nipayí

jipáyiθ hipáte
jipáyin hipáne
jipá hipáʔ
injipáh

But they are sadly rare

[bradrn]

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

Well found! What’s happening here is that the first +Str+None is being wrongly treated as an intersection because of the initial + sign. There’s a bit of code which was intended to fix that for the first thing in a category (where it’s confusing), but it looks like I didn’t write it quite carefully enough. The bug is now fixed in the code.

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

In somewhat happier news, I got round to trying the paradigm builder. I really like it; very useful in developing paradigms¹. There does seem to be a small bug where line breaks are treated as a signal to stop, even if there are more lines with stuff in below, but other than that, I really like it. I do have feature requests though:

I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!

Firstly, and most simply², I'd appreciate being able to be able to select whether one of a set of features are present, so if I write something like

Code: Select all

NOM ACC GEN
SG PL
(NOM or ACC) PL > 1.i
GEN PL > 1.o
GEN SG > 1.a
ACC > 2.s
GEN > 2.n

I'd get
test testi
tests testis
testan teston

That makes sense, and shouldn’t be too hard to implement.

Secondly, I'd like to be able to combine sound changes with the paradigm builder without having to copy-paste.

Hmm… not sure I love the idea of merging the two. I’ll have a think about it.

(One thing you can do currently is to generate a set of words using ordinary sound changes: start with a ‘word’ like 12345, and then you can write 1 / [p t k], 2 / [a e i o u], etc.)

Lastly, I'd like the ability to select between different stems for a word.

This is one of the big gaps in the paradigm builder currently. (I’d say the other major one is infixes.) I dearly love my stem alternations, so I’ve thought a bit about this myself, but I’m unsure what would be the best design. But what you suggest looks really sensible… certainly I can continue thinking about this.

[Lērisama]

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

Well found! What’s happening here is that the first +Str+None is being wrongly treated as an intersection because of the initial + sign. There’s a bit of code which was intended to fix that for the first thing in a category (where it’s confusing), but it looks like I didn’t write it quite carefully enough. The bug is now fixed in the code.

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

Thank you¹²

There does seem to be a small bug where line breaks are treated as a signal to stop, even if there are more lines with stuff in below, but other than that, I really like it. I do have feature requests though:

I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!

Good to know. I don't know if you saw the bolded bit of my quote, since you didn't respond, and it was a bit hidden in the text, so I'm saying now to make sure.

Secondly, I'd like to be able to combine sound changes with the paradigm builder without having to copy-paste.

Hmm… not sure I love the idea of merging the two. I’ll have a think about it.

Me neither, that was born of late night frustration³ with copy-paste, and I might not have said it otherwise. Feel free to ignore that one – it's certainly manageable without it

This is one of the big gaps in the paradigm builder currently. (I’d say the other major one is infixes.) I dearly love my stem alternations, so I’ve thought a bit about this myself, but I’m unsure what would be the best design. But what you suggest looks really sensible… certainly I can continue thinking about this.

Oh gosh, infixes… that'd be a pain to implement. I'm also a fan of stem alternations⁴. I'm excited for a future expanded paradigm builder. Paradigms are painful to do by hand.


¹ In case anyone else gets confused by this, because I spent a few minutes checking, this change isn't released yet, so the bug is still present on the online brassica
² Also, thanks for making me aware of the [tt] tag from me quoting this. No more ugly code blocks breaking up my posts!
³ I wrote this last night as notes, and then filled it out and posted it this morning because I was too tired. The result is a post different to what I would have written at either time
⁴ LZ has seven in its evilest verbs, although only three main ones (the rest are phonologically conditioned variants)

[bradrn]

There does seem to be a small bug where line breaks are treated as a signal to stop, even if there are more lines with stuff in below, but other than that, I really like it. I do have feature requests though:

I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!

Good to know. I don't know if you saw the bolded bit of my quote, since you didn't respond, and it was a bit hidden in the text, so I'm saying now to make sure.

Yes, I saw.

This is one of the big gaps in the paradigm builder currently. (I’d say the other major one is infixes.) I dearly love my stem alternations, so I’ve thought a bit about this myself, but I’m unsure what would be the best design. But what you suggest looks really sensible… certainly I can continue thinking about this.

Oh gosh, infixes… that'd be a pain to implement. I'm also a fan of stem alternations⁴. I'm excited for a future expanded paradigm builder. Paradigms are painful to do by hand.

Actually, IIRC a previous program of mine did support infixes, I think by letting you put numbers in the middle of roots to show where they should go. But I’m not sure that’s the best way to do it…

¹ In case anyone else gets confused by this, because I spent a few minutes checking, this change isn't released yet, so the bug is still present on the online brassica

Yes, hence why I specified ‘in the code’. (It’s late and now I’m the tired one… I should communicate more clearly.)

[Lērisama]

I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!

Good to know. I don't know if you saw the bolded bit of my quote, since you didn't respond, and it was a bit hidden in the text, so I'm saying now to make sure.

Yes, I saw.

Good to know

¹ In case anyone else gets confused by this, because I spent a few minutes checking, this change isn't released yet, so the bug is still present on the online brassica

Yes, hence why I specified ‘in the code’. (It’s late and now I’m the tired one… I should communicate more clearly.)

I completely missed that, sorry