In-situ wh-words in languages which also do extraction

HPSG
22

OK, I will perhaps try that (L-PERIPH constraints) for the in-situ-ques-phrase.

As for head-adjucnt rule double-firing:

It seems that, to rule out head-adj attaching both before and after subject extraction, head-adj should be constrained to have SLASH-empty head daughters (and that will not get in the way of who where sleeps because that’s adj-head).

For some reason I can’t do that and I can’t figure out why. sleeps where can form a VP but then subject extraction does not want to apply to that VP. The unification failure has to do with the mother’s SLASH value (in the APPEND) but I don’t quite understand why.

Screen Shot 2020-01-28 at 10.39.19 AM
Screen Shot 2020-01-28 at 10.39.19 AM1684×1080 16.2 KB

It seems to me that the head-adj rule is appending SLASH lists of its daughters (scroll all the way):

my-head-adj-phrase := head-adj-int-phrase &
  [ HEAD-DTR.SYNSEM [ LOCAL.CAT [ HEAD +nv ],
                      NON-LOCAL.SLASH.LIST < > ],
    NON-HEAD-DTR.SYNSEM.LOCAL.CAT.VAL.COMPS < > ].

head-adj-int-phrase := head-adj-phrase & isect-mod-phrase.

head-adj-phrase := basic-head-mod-phrase-simple & head-initial & phrasal &
  [ SYNSEM.MODIFIED rmod,
    NON-HEAD-DTR.SYNSEM [ LOCAL.CAT [ VAL.SPR olist,
                                      POSTHEAD + ] ] ].

isect-mod-phrase := basic-head-mod-phrase-simple & head-compositional &
  [ HEAD-DTR.SYNSEM.LOCAL [ CAT.MKG #mkg, CONT [ HOOK.LTOP #hand ] ],
    NON-HEAD-DTR.SYNSEM.LOCAL [ CAT [ VAL.SPR adv-list,
                                      HEAD.MOD < [ LOCAL intersective-mod & [ CAT.MKG #mkg ] ] > ],
                                CONT.HOOK.LTOP #hand ],
    C-CONT [ HCONS 0-alist,
             ICONS 0-alist ] ].


basic-head-mod-phrase-simple := head-mod-phrase & binary-headed-phrase &
  [ SYNSEM [ LOCAL.CAT.MKG #mkg,
             NON-LOCAL [ SLASH.APPEND < #s1, #s2 >,
                         REL 0-alist, QUE.APPEND < #q1, #q2 > ] ],
    HEAD-DTR.SYNSEM
           [ LOCAL [ CAT [ HEAD #head,
                           VAL #val,
                           POSTHEAD #ph,
                           MC #hmc,
                           HC-LIGHT - ],
                     CONT.HOOK #hdhook & [ ICONS-KEY.IARG1 #clause,
                                           CLAUSE-KEY #clause ],
                     AGR #agr ],
             NON-LOCAL #nonloc &
                   [ SLASH #s2, QUE #q2 ],
             LIGHT #light,
             MODIFIED #modif ],
    NON-HEAD-DTR.SYNSEM
           [ LOCAL [ CAT [ HEAD [ MOD < [ LOCAL local &
                                              [ CAT [ HEAD #head,
                                                      VAL #val,
                                                      POSTHEAD #ph,
                                                      MC #hmc ],
                                                AGR #agr,
                                                CONT.HOOK #hdhook ],
                                          NON-LOCAL #nonloc,
                                          LIGHT #light,
                                          MODIFIED #modif,
                                          OPT - ] > ],
                           VAL [ COMPS olist,
                                 SPR olist ],
                           MKG #mkg ],
                     CONT.HOOK [ ICONS-KEY.IARG1 #clause,
                     CLAUSE-KEY #clause ] ],
             NON-LOCAL [ SLASH #s1, QUE #q1 ] ],
    C-CONT [ RELS.LIST < >, ICONS.LIST < > ] ].

The subject extraction rule:

extracted-subj-phrase := basic-extracted-arg-phrase & head-compositional &
  [ SYNSEM.LOCAL.CAT.VAL [ SUBJ < >,
                           SPR < >,
                           COMPS < > ],
    HEAD-DTR.SYNSEM.LOCAL.CAT [ VAL [ SUBJ < gap &
                                             [ LOCAL local &
                                                     [ CONT.HOOK.INDEX ref-ind ] ] >,
                                      COMPS < > ],
                                MC na ],
    C-CONT [ RELS.LIST < >,
             HCONS.LIST < >,
             ICONS.LIST < > ] ].

Which part is making ex-subj applying to the VP formed by head-adj impossible? It seems like maybe it is the APPEND in basic-head-mod-simple?.. Somehow.

23

How is the L-PERIPH feature suppose to percolate, exactly?.. I am not sure I understand how this would work with embedded clauses.

Do we start with one clause, make sure we set L-PERIPH correctly with respect to the combination of head-sibject/subj-head and head-comp/comp-head rules, then, if we have a clause-embedding verb, we just reset it or something?

From Sanghoun’s book: “A [ L-PERIPH + ] constituent must be left-peripheral (cannot be combined with anything on its left”. But I am not sure how this is supposed to be ensured; via considering various subj/comp/head combinations?.. (That’s what it looks like in the information structure library).

24

I think this is lexical threading biting you again :slight_smile: Even if extraction is applying higher, the SLASH value of the VP will have to be compatible with non-empty for it to apply.

25

Hmm – I’m not entirely sure that L-PERIPH is the right place for this, if it’s just a binary feature. What you want is called an “edge” feature, like L-PERIPH, whose value is propagated up the left edge of the structure. Let’s make up a new feature, called L-QUE, which is appropriate for all signs. In phrases, its value is the same as the QUE value on the first element of ARGS (i.e. the first daughter). Would that do what you need?

26

So, no immediate good way of doing this then? Have to live with the ambiguity for now, with head-adjunct phrases?

27

One idea: The SUBJ value on the daughter is a list of things of type canonical-synsem. You’d probably need to make a new parameterized type for this. The idea is that the SUBJ value is either empty, or if non-empty, corresponds to an argument that can’t itself be a gap.

28

This is the head daughter of the head-adjunct rule?

29

Yes. (Discourse won’t let me say just yes, though, that’s too short.)

30

Could you elaborate? Indeed this:

my-head-adj-phrase := head-adj-int-phrase &
  [ HEAD-DTR.SYNSEM.LOCAL.CAT [ HEAD +nv,
                                VAL.SUBJ < canonical-synsem > ],
    NON-HEAD-DTR.SYNSEM.LOCAL.CAT.VAL.COMPS < > ].

seems to mean a non-empty subject (as I’d expect). What should the SUBJ value look like?

Oh, is it like a list AND a canonical-synsem?

31

I tried the above this way:

nongappy-list := canonical-synsem & list.

But this doesn’t want to unify with a null subject nor with a cons subject, so, that’s wrong…

32

Trying also:

nongappy-list := list & 
[ FIRST canonical-synsem ].

but that doesn’t load; the geometry is wrong I think because FIRST is only introduced for subtypes of list…

33

You need to build something parallel to olist:

; A list of optional arguments.
olist := list.

ocons := olist & cons &
  [ FIRST unexpressed & [ OPT + ],
    REST  olist ].

onull := olist & null.
34

I see, something like that?

; A list that is either empty or contains canonical-sysnems,
; so, no gaps.

clist := list.

ccons := clist & cons &
  [ FIRST canonical-synsem,
    REST  clist ].

cnull := clist & null.

But that’s either not quite right or I am not using it right:

my-head-adj-phrase := head-adj-int-phrase &
  [ HEAD-DTR.SYNSEM.LOCAL.CAT [ HEAD +nv,
                                VAL.SUBJ clist ],
    NON-HEAD-DTR.SYNSEM.LOCAL.CAT.VAL.COMPS < > ].

because I still have the head-adjunct rule taking a wh-question as its head daughter, like in the left tree (again, pseudolanguage below):

Screen Shot 2020-01-29 at 11.50.18 AM

That’s what we’ve been trying to rule out, right?

Well I guess not, because if it is a question sentence, then its SUBJ is in fact empty… Hm.

35

Yeah! That works well except like you said, it breaks the V-initial sentences. But those I really have long wanted to license by some information structure rule which puts heavy stress on the wh-word. So I kind of am not sad to lose them at this point.

36

I thought you were trying to rule out order of application ambiguity between subject extraction and modifier attachment. That’s what clist should be good for.

37

OK, right, and it is!

As for the above, I think L-QUE could work here as well: don’t attach a modifier to a sentence which starts with a question word. Assuming that semantically, it doesn’t quite make sense to attach a modifier to a complete question sentence?.. I don’t think?

With this change (adding L-QUE.LIST < > on head-adjunct’s head daughter, I didn’t get any regressions in my Russian test suite but I may be missing the right test items…

Does it sound to you like this is reasonable or does it sound I’d be ruling out something good?

Or would it rule out something good…

38

So if instead of type append-list, we want to propagate an additional boolean value WH +/-, so as to ultimately rule out WH + items in the left periphery of head-adjunct and in-situ-question clauses, where should such a feature live on the lexical items?

39

Let’s put it parallel to L-PERIPH, since it gets passed through the trees in roughly the same way.

40

OK; this seems to mostly work but I think I need to do something about lexical rules also, for them to propagate the value.

So perhaps the phrase-or-lexrule type should be doing it.

41

So I now have a situation that seems parallel to what we discussed about head-adjunct and subject extraction, for which @ebender suggested the new list type which I then called clist, for a list of canonical synsems.

Screen Shot 2020-01-29 at 5.36.42 PM
Screen Shot 2020-01-29 at 5.36.42 PM738×474 3.94 KB

It would be ideal to also rule out this ambiguity in the order of head-adjunct and extracted-complement application.

But adding a [ COMPS clist ] constraint to the head-adjunct’s head daughter leads to ruling out all parses. This is because the basic-head-filler phrase says its arguments’ COMPS are of type olist (maybe; I am actually not clear on why I didn’t hit this with the SUBJ).

Screen Shot 2020-01-29 at 5.54.07 PM
Screen Shot 2020-01-29 at 5.54.07 PM1186×804 9.78 KB

Seems like meddling with that would potentially break argument optionality. And I did not have to meddle with anything like that to fix the SUBJ issue. What do you think, @ebender, do you see right away at what level the olist constraints could be changed? Or can we make clist cross-typed with olist somehow?