Unification failure involving zero-arg-... type hierarchy

Grammar Matrix
#1

I introduced a new NON-LOCAL feature called YNQ for second position question clitics (per LING567 analysis).

I then realized that I didn’t properly add it everywhere, like there is the zero-arg-que type which allows a non-empty QUE, and then there is zero-arg-nonque which insists on an empty QUE, etc. In my current version, YNQ is often underspecified because I did not integrate it into the lex-item hierarchy. So I did integrate it now like so (please scroll down):

; basic_zero_arg lexical items have empty ARG-ST lists.  They may
; introduce a non-empty value for one of the non-local features.

basic-zero-arg := lex-item &
  [ ARG-ST < > ].

zero-arg-nonslash := basic-zero-arg &
  [ SYNSEM.NON-LOCAL.SLASH.LIST < > ].

zero-arg-nonrel := basic-zero-arg &
  [ SYNSEM.NON-LOCAL.REL.LIST < > ].

zero-arg-nonque := basic-zero-arg &
  [ SYNSEM.NON-LOCAL.QUE.LIST < > ].

zero-arg-nonynq := basic-zero-arg &
  [ SYNSEM.NON-LOCAL.YNQ.LIST < > ].


; Non-argument taking items which introduce no non-local values.

norm-zero-arg := zero-arg-nonslash & zero-arg-nonrel & zero-arg-nonque & zero-arg-nonynq.

; Items introducing a rel value.

zero-arg-rel := zero-arg-nonslash & zero-arg-nonque & zero-arg-nonynq.

; Items introducing a que value.

zero-arg-que := zero-arg-nonslash & zero-arg-nonrel & zero-arg-nonynq.

; Items introducing a slash value, e.g., resumptive pronouns in French.

zero-arg-slash := zero-arg-nonrel & zero-arg-nonque & zero-arg-nonynq.

; Items introducing a ynq value, e.g., second position question clitics.

zero-arg-ynq := zero-arg-nonrel & zero-arg-nonque & zero-arg-nonslash.

Then I said that second position question clitics are actually zero-arg-ynq:

; Second position question particles are treated as modifiers.

ques-clitic-lex := no-hcons-lex-item & zero-arg-ynq &
  [ SYNSEM [ LOCAL [ CAT [ VAL [ SPR < >,
                                 COMPS < >,
                                 SUBJ < >,
                                 SPEC < > ],
                           HEAD adv &
                                [ MOD < [ LIGHT +,
                                          LOCAL intersective-mod &
                                                [ CAT.HEAD +nvrpd ],
                                          L-PERIPH +,
                                          L-QUE - ] > ] ],
                     CONT.RELS.LIST < > ],
             NON-LOCAL [ SLASH.LIST < >,
                         REL.LIST < >,
                         QUE.LIST < >,
                         YNQ.LIST < *top* > ] ] ].

And now the grammar does not compile saying there is a unification failure between YNQ.LIST cons and null, so, something is saying YNQ.LIST is empty.

But what? I meant zero-arg-ynq to say it can be non-empty, modeling it off of the rest of the hierarchy.

What am I missing?

#2

I would start debugging by removing zero-arg-ynq from the supertypes of ques-clitic-lex so that the grammar compiles. Then look at the “expanded type” for ques-clitic-lex and zero-arg-ynq…

#3

Yup, I did exactly that, and zero-arg-ynq says its YNQ.LIST is empty! But why?..

#4

Ah! Found it, using the “type hierarchy” feature in the LKB. I had added something called non-ynq-word also, said basic-zero-arg inherited from it (don’t know why), and forgot about it :).

#5

Actually, I now wonder if that is not better anyway. This YNQ feature is only needed for second position question clitics, so, perhaps there is no need to integrate it any further into the matrix core. In fact I’ve been planning to do the opposite.

#6

Whether the YNQ feature is added only in the libraries or part of the core, you’ll still need the same solution though, won’t you?

#7

Maybe; right now the question clitic is not inheriting from any of the zero-arg-… types and simply specifies all the NON-LOCAL features (should probably also specify an empty ARG-ST :smiley:) . basic-zero-arg is constrained to have empty YNQ. It’s not very general but was much easier to write, I guess :slight_smile: (I no longer remember exactly what I was thinking etc. I suspect I was doing this part in a hurry. I remember thinking: I will just add this piece as it is in the 567 instructions, even though I know it won’t be very well integrated that way).

Do you think I should instead do a proper hierarchy?

#8

I dived a little bit in the adverbs type hierarchy and I think see now that it would be best to have the general solution (unsurprisingly). Otherwise, I had an adverb type say it is YNQ < > (clearly for a reason; something was overgenerating), and it is cumbersome to try and add it in the customization system unless there is a type like norm-zero-arg (to which YNQ constraint had been added, when appropriate).