It might make sense to do Yukaghir last, indeed. If the PC is already attaching to just one type of verb, then it seems like you should only create WH rules that pertain to that type of verb in that PC. (In other words, the pseudo-feature would be interpreted differently depending on its context.)
Yes, that’s what I thought. But I am not sure that’s not a complete nightmare, at this point…
Maybe it doesn’t have to be and I am just confused. For every LRT I am looking at at any point, I certainly know the PC and its supertypes. So then creating WH-rules which only take that PC as input should not be tricky as such. The problem remains how to tell whether the PC is transitive or intransitive though, and that’s a bit unpleasant like I said (unless I am missing something else).
As a technical solution: I agree with @ebender that you can use a parametrised list, so you shouldn’t need to check if a verb is transitive or not. (If you need to append to these lists, remember to create
list-copy subtypes, as explained here.)
But I also have a question about the analysis. How does morphological marking work with embedded clauses? If you had a question like “Who does Kim think arrived?”, but the wh-word is in situ, so in pseudo-English “Does Kim think who arrived?”, what happens to the morphological marking of “arrived”? Maybe this isn’t an issue for Yukaghir, but I could imagine a language where the morphological marking on the verb refers to sentence force, not the presence/absence of wh-words. So maybe the analysis should be that the in-situ rule which discharges QUE is blocked in that clause, not that QUE is empty.
I think you’re making it harder than it needs to be. Transitive/intransitive is only relevant to rules that attach directly to the verb stem and say specifically intransitive or transitive.
I really hope so!!!
So, something like this then? (It seems to work, at least for the one morphological language that was working before, with the four rules, but I am not sure whether I need exactly this, or something else, or less than this. I modeled this off of the clist.)
non-wh-list := list. non-wh-cons := non-wh-list & cons & [ FIRST canonical-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 is missing here?
And remember the
-copy subtypes, too, if you need to append to these.
Right… So, for the clist (the list of canonical-synsem), the ccons & cons type did not actually work, and we left it out, which was somewhat dissatisfying. The same problem occurs if I try adding the non-wh-ocons type.
Maybe I should not be using canonical-synsem here in non-wh-list? Which type should I be using? Just synsem seems to work.
I don’t follow. What is dissatisfying?
If two parametrised list types have incompatible constraints on the elements of the list, then the only possible list which is of both types is an empty list. So in this case you just need
non-wh-onull := non-wh-null & onull. Then if you unify
olist, you correctly get an empty list (
non-wh-onull, which is a subtype of
non-wh-olist type is unnecessary – it has no subtype which is nonempty, but it also isn’t a subtype of
I don’t know. Emily said it was brittle (in the link above).
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:
null. For a special subtype of
list to work properly, it also needs to have corresponding subtypes of
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-null. And similarly if we have another type
y-list, we need
y-null. Now, if the constraints for
y-cons are compatible, then we can also define
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
- if the constraints are meant to be incompatible, just define the
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.
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).