No lexical threading and morphological marking of questions

Sorry, I don’t really understand this well enough to follow! I mean, this entire part of the grammar. I can add whichever hierarchy makes sense (to others). Right now I have:

non-wh-list := list.

non-wh-cons := non-wh-list & cons & 
[ FIRST synsem & [ NON-LOCAL.QUE.LIST < > ],
  REST non-wh-list ].

non-wh-null := non-wh-list & null.

non-wh-olist := non-wh-list & olist.

non-wh-onull := non-wh-null & onull.

non-wh-ocons := non-wh-cons & ocons.

This does not lead to any errors. If I use canonical-synsem, I will get an error unless I get rid of non-wh-ocons.

I can edit this as necessary but I don’t myself understand what it should be.

Above you were first talking about non-wh-ocons but then switched to non-wh-olist; I am not sure how the two issues relate to each other, or or if they don’t, then what exactly I should do about either of them?

I talked about the types together, because they only make sense together. To work properly, lists require three types: list, cons, null. For a special subtype of list to work properly, it also needs to have corresponding subtypes of cons and null. If you just have cons, the list could never terminate. If you just have null, the list must be empty.

So for example, if we have one parametrised list type x-list, we need to define x-cons and x-null. And similarly if we have another type y-list, we need y-cons and y-null. Now, if the constraints for x-cons and y-cons are compatible, then we can also define xy-list, xy-cons, xy-null. If the constraints are not compatible, then we cannot define xy-cons. But remember we need all three types for a list type to work properly. Without xy-cons, there’s no point defining xy-list. But we can still define xy-null on its own, as a special kind of empty list.

So if you want to have a common subtype of two special list types:

  • if the constraints are meant to be compatible, define three types (for list, cons, null)
  • if the constraints are meant to be incompatible, just define the null type
1 Like

Going back to the general question of how to handle question morphology without lexical threading:

Wouldn’t creating two separate lexical rule types for wh-subj and wh-obj instead of the one specified by the user be generally problematic? If there are other position classes for which that user-specified one is input, that just becomes a bit of a morphotactics library nightmare (unless I am missing some simple way of doing it).

My motivation for those two rules was Yukaghir but I actually now see that Yukaghir does something different: it requires a lexical rule for just polar questions and a lexical rule for both polar and wh. But it does not in fact require a lexical rule for just wh questions. And I was not able to find examples of that in other languages, either.

So, perhaps just the three-way distinction:

(1) a general interrogative rule type (SF ques)
(2) a non-interrogative type (SF prop)
(3) a polar type ( := interrogative & [ SUBJ|QUE < >, COMPS non-wh-list ]

This works for Yukaghir. If a rule is for both polar and wh, it is simply an interrogative rule. No need for special QUE constraints for subject and object beyond (3)?

And the wh-only option would be declared nonexistent/unexpected, under this analysis.

Reactions?

Olga, I still don’t follow why you think having multiple rules would require multiple position classes. If you have a position class with multiple rules in it, that isn’t attaching to only transitive or only intransitive verbs, it doesn’t matter what the rules say about the COMPS list. The grammar will still load.

I think, perhaps even regardless of that, the question is do I really need two separate rules that say: (1) the object is wh; (2) the subject is wh.

What this seems to necessitate is at least one lexical rule that isn’t called the same thing as the user specified, right? And doesn’t it become a mess at that point? Or maybe it doesn’t provided this is the same PC? I can just rename the user-specified rules whatever I like?..

(As for transitive/intransitive, Yukaghir does have such PCs.)

Right – if the extra rule is in the same PC, then you don’t get a huge morphotactics mess. The problem with your three-way distinction above is that whenever (3) could work (1) will work too, giving spurious ambiguity. So I think you do need separate rules for wh subj & complement.

So, if the user specified Rule A and then specified some morphotactic constraints or something, with respect to Rule A, wouldn’t a mess occur should I later rename Rule A into Rule B and Rule C? I was under the impression that the morphotactic library rather cares about the names of things, including rule names.

Plus, like I said, in Yukaghir there are separate intransitive and transitive position classes.

Those would normally be mutually exclusive, I think. The general “interrogative” would be added only if the user said “both polar and wh”, and I see what you mean: if I say, within the same PC, one LRT is for polar-only and another is both, then there will be ambiguity. But perhaps this (given that such choices are unlikely) is still preferable over the very convoluted solution with wh-subj and wh-obj introduced into the hierarchy instead of a user-specified rule, which I sense will break the hierarchy, and which requires multiple exceptions in methods which before that were general and straightforward—like the write_supertypes() method, which now would have to say: “uness you are an interrogative rule! If you are, check what kind, and if this kind, replace the name with X and add Y…” etc; that’s not the only change that’s required. Unless there is a simpler way of doing all of that of course, but I am not seeing it. Maybe if I do that at the point of serializing the rules into the choices file? But I doubt that that would be simple either…

Yes, fine – I can see that a little extra ambiguity is probably an okay price to pay for the simpler grammar.

I will try to revisit this issue once again once I am done with everything else. Maybe when this is the only thing I need to look at, it will become clearer to me (and I will add a couple of tests for that ambiguity).