New rule type -- add to matrix.tdl?

In order to let some of my possessors act like modifiers, I need to have inflecting rules that apply to these possessors, which A) add something to their MOD list and B) add a relation to their RELS list. This means that I need a rule like val-change-with-ccont-lex-rule, but which changes the HEAD features rather than the VAL features. It turns out that writing a supertype like this is really ungainly. You have to go up several levels in the defined lexical rule supertypes in matrix.tdl, removing one constraint and keeping the rest:


The fact that this rule is so ugly makes me think I am doing something terribly wrong. Does anyone see a way around this aesthetic trainwreck? Perhaps some intermediate levels of inheritance that group the supertypes that head-change-with-ccont-lex-rule inherits from? And where should I add such a rule – to matrix.tdl or just to the grammars where it is needed?

What does val-change-with-ccont look like? Perhaps there could be a supertype that does what’s shared between them? OTOH, you can get some of that from cat-change-only-lex-rule if the HOOK value stays the same between input and output. That won’t be true for all of Chris’s val-change-with-ccont rules.

I think what I did to arrive at head-change-with-ccont was I took out cat-change-with-ccont-lex-rule and same-head-lex-rule, and then had to go collect all their supertypes that were still relevant for what I was doing. The spacing in the head-change-with-ccont rule indicates where the constraints got picked up from. It looks like there is a more sensible way to do this:

That last clump of constraints in head-change-no-ccont only differs from local-change-only-rule in not including no-ccont-rule; I could make a new type called local-change-with-ccont-rule that is identical except for excluding no-ccont-rule.

The middle clump is likewise almost exactly like cat-change-only-lex-rule, except that that type inherits from local-change-only-rule. Unfortunately, a type called cat-change-with-ccont-rule was already created, which inherits from same-modified-rule, so I would need a different name. Maybe cat-mod-change-with-ccont-rule? That’s not particularly informative, as names go. Whatever this type was called, it would inherit from local-change-with-ccont-rule.

Then my supertype here would be almost exactly like head-change-only-rule which is currently in matrix.tdl, except it would inherit from cat-mod-change-with-ccont-rule.

Would people be comfortable with me adding local-change-with-ccont-rule, cat-mod-change-with-ccont (or some better name), and head-change-with-ccont-rule to matrix.tdl?

To make this less confusing, here’s what I’m proposing adding to matrix.tdl:


That’s essentially the approach I followed: where one of the matrix.tdl rules was almost right, except for some constraint, I created a less-restrictive variant. That also ended up being repeated at multiple levels of rules in some cases, where a constraint got carried up through the hierarchy. My rough heuristic for what went into matrix.tdl was: varying constellations of general constraints similar to the ones already there went in; anything that specifically implements valence-changing morphology went to my library.

Yep, those “clumps” are what I ended up doing as well. I think in a couple cases it made more sense just to un-clump, but mostly just created variations minus the problematic same-xxx constraint.

1 Like

This looks sensible to me!

1 Like