Determining whether an ICONS change is good

(related to this: InfoStr regression tests: running them with rtest)

I am looking at a regression test failure which is due to ICONS being empty in the gold profile and non-empty in current. Trying to understand why that is and what the course of action should be.

Right now I am looking at a Turkish sentence from a clausal complements test, licensed ultimately by the decl-head-opt-subj rule:

(1) Senim sinemaya     gelmeni  istiyorum
     2sg   cinema.DAT come.NMZ want.1SG
`I want you to come to the movies.' [tur]

In both the trunk and my current branch, both the tree and the simple MRS, as displayed by the LKB, look like this:

But indeed, ICONS is empty in the top node in the trunk and is not empty in my current branch (even though that is not displayed by the LKB).

As discussed in the other thread, the classic regression testing system ignores such diffs but it is probably wrong to ignore them as ICONS is meaningful.

So I need to decide what to do in such cases (there are loads of them).

There are no ICONS-related differences in ccomp-illustr2-tur.tdl, between my version and the trunk.

As for matrix.tdl, of course the type of ICONS was changed everywhere from diff-list to append-list, but I doubt that’s the reason since we saw these diffs with rtest before I ported append-lists.

Looking at this particular sentence and the local AVMs in the parse, the non-empty ICONS seems to be introduced by the topmost rule, the decl-head-opt-subj.

decl-head-opt-subj-phrase := basic-head-opt-subj-phrase & declarative-clause &
  [ SYNSEM.LOCAL.CAT.MC #mc,
    HEAD-DTR.SYNSEM.LOCAL.CAT.MC #mc ].

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 ],
		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 ],
								       ICONS-KEY #ikey,
								       CLAUSE-KEY #ckey ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS 0-alist,
	     HCONS 0-alist,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

The above does not differ between the trunk and my branch apart from the diff-list vs. append-list syntax.

So indeed the ICONS should never be empty, it seems, if a node was licensed by this rule.

So, ultimately, it seems like in such cases, the gold profile should be updated (right?).

How did the gold profiles end up without ICONS? We talked about locating the initial commit but perhaps in such cases, I do not necessarily need to find out? One guess could be that they predate the Info Structure library but that certainly isn’t true about my clausal complements tests.

To add to the mystery, there are other sentences in the same test, licensed by the same top rule, which properly have non-empty ICONS in both gold and current profiles.

Interesting – it’s puzzling to me that this example should have gone from ICONS-less to ICONS-full, especially given that you added the test after Sanghoun’s library was complete.

However, I don’t see anything in the tdl you’ve posted that is actually adding anything to the ICONS list. [ COG-ST in-foc ] is a property recorded on the INDEX of the dropped subject, i.e. in the RELS list, ultimately. (That’s about discourse status, not information structure, despite the ‘foc’ in the value ‘in-foc’.) ICONS-KEY and CLAUSE-KEY are pointers that are used when adding something to the ICONS list, but nothing here is actually talking about C-CONT.ICONS.

Oh oh, try scrolling though! I think you haven’t actually seen the entire rule (it’s not obvious). Here is the part that it doesn’t immediately show unless you scroll:

 C-CONT [ RELS 0-alist,
	     HCONS 0-alist,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

Oh! Indeed – I didn’t realize that there was anything that should scroll there. Thanks for the heads up. Yes, in that case, there should be a non-empty ICONS value here and you can update the gold. It would be interesting to know how the ICONS was missing in the earlier one, but especially as this is a regression test to do with something orthogonal, I don’t think you need to dig it up.

…especially why in some cases, there is a non-empty ICONS in the gold and in others there isn’t! For sentences licensed by this same very rule! So puzzling.