Code: Select all
o /Code: Select all
xo xȍCode: Select all
x x̏Code: Select all
xő xCode: Select all
filter: o(?=\w|$) > ! You use Brassica's multigraph support. In the initial categories block, you would have a statement like thisNeonnaut wrote: ↑Fri Dec 06, 2024 10:01 am The workaround in Lexifer is to say in the rulewhich produces said expected results. But how would you solve this in Brassica?Code: Select all
filter: o(?=\w|$) > !
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 / ŋ
Code: Select all
xo → x
xȍ → xȍ
xong → xŋ
xȍng → xȍŋ
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
Code: Select all
o ́ / ó
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 wrote: ↑Fri Dec 06, 2024 7:03 pm 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]:
(Where there’s a space between the characters on the left-hand side.)Code: Select all
o ́ / ó
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).
Luckily, Haskell has such a function! (In the base library, no less.)Travis B. wrote: ↑Fri Dec 06, 2024 8:17 pmIt 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 wrote: ↑Fri Dec 06, 2024 7:03 pm 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]:
(Where there’s a space between the characters on the left-hand side.)Code: Select all
o ́ / ó
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).
I suspected it might have such a thing.bradrn wrote: ↑Fri Dec 06, 2024 9:06 pm Luckily, Haskell has such a function! (In the base library, no less.)
It works for me, but I don't know if it was ever down for me, as I didn't test it then
Looks like the server got shut down again, so I booted it back up. Looks like it’s working now.Man in Space wrote: ↑Wed Dec 18, 2024 7:35 pm It's down again. If it does load, the font's all wrong and you can't open or type anything.
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
Code: Select all
V = &+Str+None &+Str+Sec &+Str+Pri
Code: Select all
V = &&Str
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
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
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
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 don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!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:
That makes sense, and shouldn’t be too hard to implement.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 likeI'd getCode: 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
test testi
tests testis
testan teston
Hmm… not sure I love the idea of merging the two. I’ll have a think about it.Secondly, I'd like to be able to combine sound changes with the paradigm builder without having to copy-paste.
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.Lastly, I'd like the ability to select between different stems for a word.
Thank you¹²bradrn wrote: ↑Sat Dec 21, 2024 5:48 amWell 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.
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.I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!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:
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 itHmm… not sure I love the idea of merging the two. I’ll have a think about it.Secondly, I'd like to be able to combine sound changes with the paradigm builder without having to copy-paste.
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.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.
Yes, I saw.Lērisama wrote: ↑Sat Dec 21, 2024 6:21 amGood 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.I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!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:
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…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.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.
Yes, hence why I specified ‘in the code’. (It’s late and now I’m the tired one… I should communicate more clearly.)¹ 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
Good to knowbradrn wrote: ↑Sat Dec 21, 2024 6:43 amYes, I saw.Lērisama wrote: ↑Sat Dec 21, 2024 6:21 amGood 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.
I don’t often use it, actually; it could do with a lot of work. Bug reports and feature requests would be greatly appreciated!
I completely missed that, sorryYes, hence why I specified ‘in the code’. (It’s late and now I’m the tired one… I should communicate more clearly.)¹ 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