What are ICons in PyDelphin?

The documentation says that an ICons constraint is just an individual constraint between variables. If I am composing MRSs together and I am trying to keep track of variable identities (e.g. x1=x4 where x1 is the variable of some ARG1 and x4 is some intrinsic variable that I wish to fill out ARG1), would using ICons be an appropriate way to store all of these identities?

EDIT: I see that delphin.mrs.is_connected (possibly?) checks for label/argument identities, etc. I don’t see it checking for anything in ICons so how would I store the things I want to be equated such that this function will recognize them? Since I assume if it passes that check then I successfully created a well formed MRS.

Hmm, if it is the same ICONS, then in principle, they have so far been used mostly for information structure: MatrixDoc_InformationStructure · delph-in/docs Wiki · GitHub
But I don’t have a more complete answer, so hopefully someone else will respond.

As I understand what you are doing, @ecconrad, this doesn’t match the usual use case for ICONS. Those are identities beyond the ones that we want to produce through unification in the grammar. I think you want a place to store identities before you go through and compute them, leaving an MRS with e.g. only x1 and no more x4 (in your ex).

Using ICONS for this won’t get you any benefits. It might also eventually cause problems, if you wanted to produce MRSes for input to the generator that had (actual) ICONS information. (Though I doubt you’ll need that any time soon.)

Unlike HCONS which have the finite set of relations qeq, lheq, and outscopes, ICONS relations can be any symbol (a string that can be a TDL identifier). However, a symbol not defined by the grammar would be pretty useless and may cause errors during processing. If you are constructing MRSs programmatically and need somewhere to store the fact that two individual variables are equated, I see no reason why you shouldn’t use ICONS to do that, e.g., ICONS: < x1 eq x4 >, assuming the following:

  1. eq or whatever relation name you choose is not used for another purpose in the grammar
  2. You resolve the equalities when you’re done assembling the MRS (e.g., by making x4 into x1 throughout, then removing x1 eq x4 from the ICONS list)

Ah, I see, thanks! Keeping track of them there also seems like a better solution than what I came up with.

Another question: as far as “making x4 into x1” … I had some trouble with this because as I was trying to edit an existing MRS it would throw the following error:

AttributeError: can't set attribute

Does this mean I should construct a new MRS from scratch as I overwrite equalities? As opposed to editing the existing one?

This is because EP.iv is a property accessor without a property setter. That is, it is only shorthand to lookup the value of the “intrinsic role” (meaning the role that maps to the intrinsic variable, or “iv”), which is, in our grammars, invariably ARG0:

I think that treating the MRS as immutable (even if it’s not), such that each edit operation yields a new MRS object with the original untouched, is a safe approach, but it will be slower if you are planning to do this on a large scale. If you want to edit an existing MRS, you can change the value of the intrinsic variable by editing the EP’s arguments:

mrs.rels[0].args["ARG0"] = 'e8'

But, of course, this is not the only place where the variable equality would need to be resolved. For instance, variable properties are stored on the MRS object keyed to the variable name.