Three Dollar Quill

All right, here we go. I figured out a basic nice interface for defining Lexurgy invocations in a Tupfile.lua, but I'm not going to be using it.

Nevertheless, I'll start off explaining it, because it makes a good starting point for the fancier stuff I have in mind.

Think of the development of a language from a protolanguage. Since I'm aiming for Old Norse, let's see what the conception of the sound changes looks like:

• Apply ablaut to increase the number of vowels.
• Proto-Indo-European to Common Germanic
• Common Germanic to Proto-Norse
• Proto-Norse to Old Norse

Now, I could stuff all of those into a single file, but I like the idea of keeping the sound changes divided, so I could, in principle, branch off from somewhere and create other members of a language family. So, rather than the single change that I specified to carry out the Basican example from Lexurgy's documentation, I need a chain of related changes for this. And those changes have some things in common, and some things different. And some of the differences are regular: the output suffix of one step must be the input suffix of the next step. Now, there are plenty of ways to express "a bunch of similar arguments" in Lua. Table arguments, varargs, probably other things than those and what I have in mind. But here is what I have in mind:

lexurgy = lexurgy or {}

local wli_template = "%s_%s.wli"
local wlm_template = "%s_%s.wlm"

do
  local function word_list(name, in_suffix, in_build_folder)
    local in_prefix
    local out_prefix = "build/" .. name
    if in_build_folder then
      in_prefix = out_prefix
    else
      in_prefix = "src/" .. name
    end
    return function(out_suffix, sound_changes)
      tup.definerule(
        {wli_template:format(in_prefix, in_suffix), sound_changes},
        "lexurgy sc --in-suffix " .. in_suffix .. " --out-suffix " .. out_suffix .. " --out-dir ../build " .. sound_changes .." " .. in_prefix .. ".wli",
        {
          wli_template:format(out_prefix, out_suffix),
          wlm_template:format(out_prefix, out_suffix),
        }
      )
      return word_list(name, out_suffix, true)
    end
  end

  lexurgy.word_list = word_list
end

Wow, I... genuinely do not know whether I'd rather build that command line with string concatenation or a format string. Python has spoiled me.

Anyway, code very much like this should work, if someone is reading this and thinking "By gosh, yes, I would like to coordinate my sound change application by simply running tup, and I'll have no truck with the other bells and whistles this post is about to add!"

However. My end goal is to generate a lexicon from this stuff, and that means not just having the evolved form of the word, but also information about how it's used. A specific line of a .wli file corresponds to a precise lineage of word, spread out across all files where the filename starts off the same. This means that, as long as I figure out a format for this metadata that all fits on one line, I don't need to further process such metadata as the sound changes are applied.

Thank you for teeing that up. While normal languages get most of their vocabulary through evolution of ancestral word forms, loan words are a thing, and it would be nice to bring in and evolve them. At this point, I can see two approaches to take with that:

• Concatenate the word lists and metadata together, creating a new single lineage, and process them as a single block at the end
• Have an array of word lists separated by origin, and combine them at the end

The former relies on the fact that the inputs to the word_list function above are sufficient to uniquely determine the location of the word list file being processed (otherwise, it couldn't process it). That means that it could "make sense" to replace the function returned from word_list with an object representing the file, and a method representing the original function, and other methods for other operations.

That was my first idea, but the more I think about it, the more I don't like it. Coordinating the concatenations feels fiddlier than I'd like right now, and requires exponentially many names for lineages. Therefore, I think I want to consider the outcome of handling lists of lineages. The in_suffix should be the same for all of them, so, hmm... Hmm...

I think I would like to finish this entry now, and ponder further after publishing.

Good night.