Error message "No possible type for features LOCAL NON-LOCAL..." (Implementing second position clitics)

I am trying to implement this analysis from 567.

Looks like I did something wrong, possibly here, though I can’t tell for sure:

non-local :+ [ YNQ append-list ].

basic-binary-phrase :+ [ SYNSEM [ L-PERIPH #periph,
             ARGS < [ SYNSEM [ L-PERIPH #periph,
                               NON-LOCAL.YNQ #ynq1 ] ],
                    [ SYNSEM [ L-PERIPH -,
                               NON-LOCAL.YNQ #ynq2 ] ] >,
             NON-LOCAL.YNQ.APPEND < #ynq1,
                                    #ynq2 > ] ].

I am getting a gazillion of errors trying to load a grammar in LKB, of this sort:

Screen Shot 2020-04-07 at 2.27.14 PM

Can someone tell what the issue is, without looking in the grammar? Otherwise if you feel generous, I will tar the grammar and send it to you :). It should be something simple, in terms of what is broken (not necessarily in terms of how to fix the general case).

You’ve got ARGS inside SYNSEM.

1 Like

Ah! Thank you :). That’s fixed now, and the next issue is with coord-phrase:

coord-phrase := binary-phrase &
  [ SYNSEM [ LOCAL [ COORD-STRAT #cstrat,
                   CAT [ HEAD.MOD #mod,
                         VAL #val ] ],
	     NON-LOCAL #nl ],
    LCOORD-DTR #ldtr & sign & [ SYNSEM [ LOCAL [ CAT [ HEAD.MOD #mod,
                                                     VAL #val ] ],
				         NON-LOCAL #nl ] ],
    RCOORD-DTR #rdtr & sign & [ SYNSEM [ LOCAL [ COORD-STRAT #cstrat,
                                               CAT [ HEAD.MOD #mod,
                                                     VAL #val ] ],
					 NON-LOCAL #nl ] ],
    ARGS < #ldtr, #rdtr > ].

That does not agree with the new append of the new YNQ feature in binary-phrase. I am getting a “cyclic check” failure on loading, specifically in the YNQ.APPEND or RCOORD-DTR.

Anything simple to be done here? Two types of binary phrases?.. But then, two question phrases usually can be coordinated… So it is not like we would want to not have the YNQ feature in coordinated phrases…

What would it mean to append YNQ values in a coordinated phrase? Could we identify SLASH but append YNQ and QUE?

I can make the grammar load if I rewrite coord-phrase to append its YNQ values. Separately from that, I don’t understand the role of the decl-cl type in the 567 analysis.

Create non-branching int-cl and decl-cl types (and associated rule instances):
int-cl := head-only & interrogative-clause &
  [ SYNSEM [ LOCAL.CAT [ VAL #val,
                                         MC bool ],
                    NON-LOCAL.YNQ <! !> ],
    HEAD-DTR.SYNSEM [ LOCAL.CAT [ MC na,
                                                           VAL #val ],
                                      NON-LOCAL.YNQ <! *top* !> ]].

decl-cl := head-only & declarative-clause & same-ynq-unary-phrase &
  [ SYNSEM.LOCAL.CAT [ VAL #val,
                                         MC bool ],
    HEAD-DTR.SYNSEM [ LOCAL.CAT [ MC na,
                                                           VAL #val ],
                                      NON-LOCAL.YNQ 0-dlist ]].

Interrogative clause OK, that’s the unary rule which ultimately adds question semantics. But why a new declarative rule? (As it is, it adds ambiguity I think, but I may not have implemented the analysis correctly… Although the MRS looks good.)

On a quick skim, it looks like that analysis was keeping phrases as [ MC na ] until either int-cl or decl-cl applied. (Don’t have time to look deeper just now.) If you aren’t using MC, then you probably don’t need decl-cl.

Hmm well MC is used pretty heavily across the libraries. I guess we’ll see. For now I have something working but it may well turn out that it doesn’t fully work, without additional MC + decl_cl stuff.

But, the idea is, first subj-head or something like that applies, the phrase is still MC na, then there is an additional unary rule (decl_cl) that turns it into a starting symbol? Do you remember what was accomplished by that, why that was needed?

Sorry, I don’t — and don’t have time to reload the analysis in those instructions into my working memory :slight_smile:

I will leave the analysis in the customization system without it for now, and we’ll see, I guess, if we find out later why this was needed.