What should the ICONS look like in argument drop? (WAS: in a clausalmod sentence)

Except… It may still be an issue with specifying the argument drop rules because now there is this asymmetry:

basic-head-opt-subj-phrase := head-valence-phrase & head-only &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL [ CAT [ VAL [ SUBJ < >,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    POSTHEAD #ph ],
		             CONT.HOOK [ ICONS-KEY #ikey,
		                         CLAUSE-KEY #ckey ] ],
		     MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ HEAD.MOD olist,
	       	      	      	      VAL [ SUBJ < unexpressed-reg &
						   [ OPT +,
						     LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST in-foc ] ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

basic-head-opt-comp-phrase := head-valence-phrase & head-only &
                              head-compositional &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL.CAT [ VAL [ SUBJ #subj,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    MC #mc,
			    POSTHEAD #ph ],
		MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ VAL [ SUBJ #subj,
					    COMPS < unexpressed &
						    [ OPT +,
						      OPT-CS #def,
						      LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST #def ],
									ICONS-KEY #ikey,
									CLAUSE-KEY #ckey ] ] . #comps >,
					    SPR #spr,
					    SPEC #spec ],
				      MC #mc,
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

I only changed how the subject drop rule works and left the object drop rule as it was. It happens to bring improvements to the tests we have (partial, in case with valchg-lkt), but this kind of asymmetry can’t be right can it? They should be doing a similar thing? But I can’t simply make them do a similar thing (as explained above; I start losing parses at that point).

This is this guthub issue.

I agree that it would make sense to treat the subject drop and object drop rules in the same way, but there isn’t enough information in this thread to debug the problem. If we’re going to use this forum like the Stackexchange sites, then we should probably have the same policy of always having a minimal working example.

The unification failure shows up on the XARG, so this doesn’t seem directly to do with ICONS directly. But there is also a problem with the ICONS, because the LIST has the same element (#11) showing up twice in the list.

My guess would be that the items on the HOOK are not being passed up correctly – in particular, I suspect there are unnecessary and conflicting HOOK re-entrancies. As I said before, I’m not fully familiar with how ICONS-KEY and CLAUSE-KEY are supposed to propagate, but I don’t think the dropped subject and object ICONS should be propagated up on the ICONS-KEY. Both rules need to add something to the ICONS list, but these are presumably as specified as they need to be, and so don’t need to be referred to again.

Hm. I think an MWE might be tricky with things like matrix grammars though; you cannot attach files. But, I suppose, possible; long files will just be truncated for the view.

Attaching the whole grammar would give a working example, but not a minimal one. In this case, the unification failure is in the XARG, but none of the given type definitions refer to XARG, so the supertypes are necessary to reproduce the problem.

1 Like

Right; wouldn’t this ultimately turn into almost the full matrix core though? If I were to include all the supertypes which are involved. I think trying to turn a matrix grammar into a MWE might not always be worth the while (although in this case it might be), so I would not make it a requirement (as in, don’t post until you’ve done it). This might be the first case which seems to motivate an MWE, and it is likely because none of us actually knows what should be done with ICONS…

Speaking of which, I agree that there is unlikely to be a need in linking ICONS-KEY to that of the dropped argument. I did try removing that constraint and since that did not fully fix the issue and none of us has a good idea what actually needs to happen (someone who will officially be working on infostructure would, eventually; my job was to fix any failing regression tests which it would be easy to fix), I decided to shelf this one for now… But, I will look again whether making the rules consistent introduces any problems.

As a side note, I think creating a MWE (or ME, at least) is something PyDelphin’s TDL module could help with. Say, you give this hypothetical debugging script a type name and path to the grammar, it looks at what features are defined on the type, then prints out the type’s definition and the (partial) definitions of supertypes where the features are constrained, along with any intervening types in the hierarchy. E.g.,:

$ inspect-type.py some-type path/to/grammar/
some-type := some-supertype &
  [ SYNSEM.LOCAL [ FEAT1 foo,
                   FEAT2 bar ] ].

; some-type inherits from the following (... means it's abbreviated)

some-supertype := some-other-supertype & ...

some-other-supertype := ... &
  [ SYNSEM.LOCAL.FEAT2 bar-or-baz,
    ... ].

I don’t have time to do this now, but it seems pretty straightforward. If this seems useful and someone else wants to give it a shot, I’d be happy to give some guidance.

2 Likes

Oooh Mike this sounds awesome. Thank you!!

Yes, that sounds very useful! Running that on all the lexical items and rules in a derivation (or an intended but failing derivation) should give something like a MWE.