Overwriting tdl added in other libraries

For some of my analyses, I need to change the definition for noun-lex that is added by lexical_items.py. For example, in one case, I need noun-lex to have a SPR that is of head type +nd rather than det. I’d prefer not to change the way noun-lex is added by default in lexical_items.py, but rather only in those cases when it’s actually necessary (even though it doesn’t cause regression tests to fail when it’s changed in lexical_items.py). Whether or not I need to make this change for a given analysis is determined by info that the user inputs on the adnominal possession subpage, so I’d rather keep any logic around this decision in adnominal_possession.py, just to make things more readable for future developers. Is it possible to add tdl in my library (which is called after lexical_items.py) that partially overwrites a tdl definition? For example, is it possible to add this tdl in my library in such a way that when contradictions between the two definitions exist, it’ll defer to the later definition?


Or do I need to deal with this in the place where it’s originally defined?

I’m pretty sure you need to put it in lexical_items.py.


If in some cases it does seem like you would really prefer to rewrite a type in your module, rather than adding a conditional statement and a call to your module in another module, I added a method called "remove_typedef() to tdl.py (in my branch for now, so you can grab tdl.py from there if you want).

So you would do something like this in your library:


In order to use this correctly though, you need to really be sure you are not removing anything useful and forgetting to include it in your new definition. So, in some cases doing it where the type is originally defined will be preferable for that reason (because you see what is being put in originally).

Ideally, we would write a more complicated method called e.g. update() which would carefully update the specific part of the definition only (similar to merge() in that sense).

I’m curious what other people think, but this sounds like a bit of a debugging nightmare to me. How will someone working on library (NB: we stopped calling them modules for a reason!) one know that constraints they are putting in are getting yanked out in library two?

1 Like

Yes, I think you are right. Probably not a good idea. (And I am using “module” in python sense :slight_smile: ).

So, any type definition is basically add-only?

That’s definitely how they are in tdl, and I think it makes sense to keep them that way in customization, unless we have a very strong reason not to.


(It’s just that having to go to the place where, say, the head-subj rule is defined and having to say: “Oh, and by the way, if this language has clausal complement strategies, let’s loop over them and if any happens to have these three choices in combination, then we need to remove the COMPS < > constraint on the head-subject rule” – is a big ugh.

But I suppose this all depends on how you do it and on choosing the lesser evil :). )

P.S.: Actually I now looked more into it and there is already something similar there having to do with auxiliaries, so, as a matter of fact, my specific issue (which is of course different from Elizabeth’s) belongs to word_order just fine.

I’m with Emily… this makes my inner software engineer cringe. :slight_smile:

If it turns out you need to do something like this, one better approach that comes to mind would be to add the less-restricted type to matrix.tdl as a supertype of noun-lex (like say, basic-noun-lex if that doesn’t exist yet); then your library would either produce your modified noun-lex when needed, or otherwise a noun-lex matching the current definition.

Or, to do something similar but keep noun-lex in matrix.tdl as-is, you could still add a supertype for noun-lex to inherit from, and then do some rewriting in your library to make nouns that need your definition get your type with the relaxed constraints.

1 Like