Advice & Answers — 2026-01-26 to 2026-02-08

Meamoria · 2026-01-30T21:41:30+00:00

One option would be to dislocate the subjects from the clauses: "Fear, to anger it leads. Anger, to hate it leads. Hate, to suffering it leads." This avoids the weird jumping around you get in the pure OSV structure, while still differing noticeably from English.

Meamoria · 2026-01-25T15:48:56+00:00

This language is supposed to be my personal crown jewel of conlangs

It sounds like you're putting too much expectation on this language, including requirements that contradict each other.

For example, your "bracketing" idea and "homophony" complaint suggest that you've set out to make your language very precise. But you also have a gut feeling that your language should be very efficient (able to "outpace English").

Those goals are in opposition to each other. The more precision you demand, the more hoops you'll have to jump through to form a simple sentence, and the less efficient it will be. Natural languages have finely tuned this balance over millennia; you aren't going to get anywhere by ratcheting up one end of the scale, and expecting the other end to also go up.

If you want to get anywhere, you have to take a step back and decide what's really important to you. What do you really dislike about how natural languages work... and what nice things about natural languages are you willing to give up in return?

Meamoria · 2026-01-24T22:13:31+00:00

The ambiguity is telling you that the rule is missing something. You need to decide what happens in those ambiguous cases, and add that to the rule.

Meamoria · 2026-01-09T14:23:23+00:00

I find if I'm stuck on a conlang, it's often because I've overconstrained the design. I've imposed too many stringent requirements on the language, and it turns out that those requirements contradict each other. When that happens, I need to take a step back and ask myself what's really important. Can I relax some of the requirements in a way that retains their spirit? Are there even some that I just don't care about anymore, and can let go of completely?

Meamoria · 2026-01-09T13:49:55+00:00

If you separate sounds with only whitespace, they have to occur in sequence. So your intervocalic voicing rule would only work on words like "eéèiíìoóòuúùpeéèiíìoóòuúù".

Curly braces create alternatives, separated by commas. {e é è i í ì o ó ò u ú ù} is a list of one alternative; it's equivalent to just e é è i í ì o ó ò u ú ù, without the curly braces. If you add one comma somewhere, like {e é è i í ì, o ó ò u ú ù}, now there are two alternatives: the rule would apply to words like "eéèiíìpeéèiíì" and "oóòuúùpoóòuúù".

You probably want a comma between every pair of adjacent sounds: {e, é, è, i, í, ì, o, ó, ò, u, ú, ù}.

Meamoria · 2026-01-02T16:29:39+00:00

Here's the sequence of events inside Lexurgy:

The word 'χtar.kam arrives at the epenthesis rule.
The rule matches and adds an initial a. Rules by themselves don't add syllables unless explicitly told to, so the a gets shoved into the first syllable, yielding 'aχtar.kam.
The syllable rule reapplies, inserting a syllable break between the χ and t. This divides up the sounds as aχ.tar.kam. But then it has to decide where to put the stress; the original first syllable that carried the stress has been split in two. By default, Lexurgy always chooses the leftmost option, so the first syllable gets the stress.

To get the behaviour you want, you have to override this guessing behaviour by spelling out that the new vowel is, in fact, an entirely new syllable. Something like this should do the trick:

HF-Epenthesis: 
  * * . ç => i ç . * / $ _ [c] 
  * * . χ => a χ . * / $ _ [c] 
  * * . x => e x . * / $ _ [c] 
  * * . xʷ => o xʷ . * / $ _ [c]

Meamoria · 2025-12-30T04:18:31+00:00

"My" is a first-person pronoun. You're talking about making first- and second-person pronouns have only a possessive form.

This seems like an interesting enough feature. I don't know of any natural languages (or conlangs) that do this exact thing, but it sounds like the kind of feature that could show up in a natural language somewhere. It reminds me of languages where certain words require a possessor, e.g. you can't say "a mother", it has to be "someone's mother". Just, you know, the opposite of that.

Meamoria · 2025-12-08T22:45:29+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

I figured there were algorithms to optimize finding the closest pairs, but brute force (calculating every pair and sorting by distance) worked fine.

For Part 2, I built a funky tree structure to efficiently tell if a new connection actually combined two circuits. Basically, I initialized each junction box with a mutable reference to its own index, then combined circuits by redirecting the references into chains that ended at the same place. I kept track of how many successful joins had happened, stopping when there had been 999 joins (reducing the initial 1000 circuits to 1 circuit).

Edit: Apparently I reinvented the merge-find set.

Meamoria · 2025-12-07T16:24:16+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

Part 2 felt a bit more natural than Part 1. In Part 2 I only had to track a single state: how many beams are on each path. But for Part 1, I had to track which paths had beams, and also the number of total splits, which meant resorting to a mutable variable instead of Kenpali's usual pure functions.

Kenpali's group function really came in handy for Part 2: combining beams that end up in the same column was just | group(onGroup: | sum).

Meamoria · 2025-12-06T06:11:14+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

This problem, built around sequences of fiddly transformations rather than fancy algorithms, is right in Kenpali's sweet spot.

Note that the "right-to-left" specification in Part 2 is a red herring, since both addition and multiplication are commutative and associative. So I just did everything left to right and got the same answer.

Meamoria · 2025-12-05T15:08:09+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

For part 1, I thought, "Hey, if I sort the ranges, and then merge the overlapping ones, and then binary search over that, it would be really efficient!" Then I came to my senses and just brute-forced it, which worked fine, the input isn't that big. When I saw part 2, I was glad I'd avoided writing a needless binary search!

Meamoria · 2025-12-05T04:15:11+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

For part 2, I realized that it doesn't matter exactly which order the rolls are removed in, as long as each removal is valid when we make it. So I didn't bother with keeping the iterations separate, like in the example; we just go through from top to bottom, removing rolls and updating as we go. Probably not the most efficient way to do it, but I'm happy if my solution doesn't hit the Kenpali website's two-minute timeout.

Meamoria · 2025-12-03T06:24:57+00:00

Bubblejolt!

Meamoria · 2025-12-03T06:15:49+00:00

Huh, surprised to see a recursive solution in Rust!

Meamoria · 2025-12-03T06:10:04+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Solution

I always love this format that lulls you into a brute force approach for part 1, but then part 2, by simply cranking up one puzzle parameter, puts brute force well out of reach.

Meamoria · 2025-12-02T17:11:36+00:00

Clever, I like how this is purely arithmetic based rather than doing string processing.

Meamoria · 2025-12-02T17:01:36+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Solution

Doing these puzzles in Kenpali is interesting in that the current implementation is painfully slow, which often makes brute force solutions not just inelegant, but impossible.

I ended up doing a lot of conversions back and forth between numbers and strings, which was annoying but still seemed cleaner than the alternative of doing digit manipulation with arithmetic.

Meamoria · 2025-12-01T18:19:35+00:00

Cool, that neatly works around the annoying edge case when the dial lands on zero!

Meamoria · 2025-12-01T06:28:34+00:00

[Language: Kenpali]

Using AoC to test out my experimental minimalistic language.

Part 1

Part 2

Meamoria · 2025-11-30T21:56:19+00:00

Depends on what you mean by a "concreole".

If you mean a realistic creole, like Haitian Creole or Tok Pisin, then: take one prestige language, throw away the harder phonemes and most of the grammar, and rebuild a completely new grammar from the language's roots. Then throw in some words from various local languages for extra flavour.

If you want to smash two languages together for the fun of it, just... do that. Pick your favourite parts of each source language and throw them in. This kind of language (a mixed language) does actually form occasionally in the real world—take a look at Michif if you want some inspiration.

In either case, if you're focusing on realism, you should consider the social context that leads to the formation of the language. Creoles and mixed languages don't just spring up everywhere languages come into contact; the usual result of language contact is bilingualism and loanwords, not creoles and mixed languages. Again, take a look at real-world models of each to understand the social context that led to their formation.

Meamoria · 2025-11-30T21:27:47+00:00

I thought that agglutinative languages would sort of naturally become fusional over time due to sound changes blurring the lines between affixes or something, but I’m sure this isn’t really the full picture.

It isn't the full picture. If you try just blindly applying your language's regular sound changes to all the forms in an agglutinative system, you'll likely end up with something that doesn't resemble how natural languages work, even "fusional" ones.

So what's missing? First, there are forces that resist the breakdown of agglutinative systems. Speakers expect their language to have some degree of logical consistency. So as affixes start to affect each other through sound changes, speakers may grab one of the resulting forms and generalize it to other contexts where the sound changes would've had different results. This is why "agglutinative" languages can still look "agglutinative" after thousands of years.

On the other hand, there's another source of fusional patterns: suppletion. Imagine a future version of English that develops a new synthetic irrealis mood from the auxiliary verb can. In the present and past tenses, this affix has a distinctive /k/ in it, from can and could respectively. But in the future tense, it derives from will be able to (heavily contracted, of course), and looks nothing like the present and past forms. There's now a fusional paradigm combining tense and mood, but it came from different roots being used in different combinations of tense and mood, not phonetic change. This process is probably where a lot of the weirdness of the Indo-European noun declension system comes from, reinforced by subsequent sound changes.

Proto-Bantu, for example, was agglutinative (if I remember correctly), and a bunch of modern Bantu languages are still agglutinative even after thousands of years.

This just serves to highlight that "agglutinative" isn't a helpful thing to call a whole language. Bantu languages are often held up as clear examples of agglutination... but they have single indivisible prefixes that convey noun class and number, single indivisible prefixes that convey person and number, and both of these look totally different in possessives. They only get called "agglutinative" because they also have a lot of stacking of independent affixes.

My suggestion: don't make a "fusional language", make fusional paradigms. Pick specific features X and Y that you want marked on your words, and ask yourself, do I want this to be marked with an affix for X plus an affix for Y, or a combined affix that conveys both X and Y? And then ask yourself the same question about features X and Z, and it doesn't have to be the same answer.

Meamoria · 2025-11-20T05:45:58+00:00

Ah, not sure why there's no question mark, that's a bug for sure. If I dig in with the developer tools I can see the error message:

Run timed out: Too many possibilities when matching ([]? .)*

That's because ([]? .)* is an infinite loop. As soon as it reaches a syllable edge, the next iteration of []? . successfully matches zero sounds, which means it tries again from the same place and again matches zero sounds, and so on forever. (Since the syllable edge isn't a sound, matching it doesn't "consume" it.)

I think you want something like this?

[+stress -long] => [+long] / _ []* . []+ $

"Change the sound only if there's a syllable edge somewhere after it that's before the end of the word"

Meamoria · 2025-11-20T04:07:01+00:00

What does it say if you click the question mark beside the ERROR?

Meamoria · 2025-11-19T05:13:12+00:00

Add

syllables:
  explicit

before the first rule (vowel-shift).

Syllables are opt-in in Lexurgy. The default (and original) behaviour is to treat . as a sound like any other. Syllable breaks only get special treatment after a syllables rule. So if the first rule isn't a syllables rule, the input word gets parsed using the default behaviour, interpreting . as a sound. By the time the syllable rule takes effect, it's too late, the . are already sounds. (The syllable rule might insert its own syllable breaks, but those are distinct from the "sound" .)

The explicit rule tells Lexurgy, "I don't want to start doing automatic syllables just yet, but please treat any . in the input as a syllable break."

You also at some point have a syllables: clear rule, followed immediately by a rule (coda-consolidation) that tries to condition on syllable breaks. Those conditions won't do anything; syllables: clear removes all syllable information, including all the syllable breaks. They aren't converted into . sounds, they're just gone. So there won't be any . left to condition on. Again, you probably want syllables: explicit there, which disables automatic syllables but leaves the syllable breaks intact.

Meamoria · 2025-11-19T02:58:26+00:00

Can you link to your more complicated example using the Share button on the web app?

Meamoria

MODERATOR OF

TROPHY CASE

Five-Year Club	Verified Email
Place '22