[developers] generation bug in Agree - "are not permitted to look you."

Woodley Packard sweaglesw at sweaglesw.org
Sun Dec 1 01:52:24 CET 2013

Spencer and Glenn,

One condition that leads to the problem here seems to be that two argument positions that were coindexed on the input (namely look's ARG1 and pron_rel's ARG0) are never unified by the proposed derivation.  This is a situation that will always fail the post-generation subsumption test.

I think the index accesibility filter idea can be extended to catch this, though the added complexity may not be worth the trouble.  In the example you gave, the pron_rel on "you" has a skolemized ARG0 (say "x1"), and the look_v_rel on "look" has a skolemized ARG1, also presumably skolemized as "x1".  The combined edge "look you" seals off the AVM node for the pron_rel's ARG0 without unifying it with look_v_rel's ARG1.  When doing the inaccessibility filter, we would normally say that "x1" was previously accessible (on both daughter edges) and is still accessible on the combined edge "look you", since it is the HOOK.XARG.  The extra trick would be to notice that in a situation where two edges that both have "x1" accessible are combined:
  1. If "x1" is still accessible on the new edge, the result is only valid if each accessible "x1" AVM node in the daughter edges becomes reentrant with some accessible "x1" in the new edge.  This fails for the example.
  2. If "x1" is inaccessible on the new edge, the result is only valid if all the accessible "x1" AVM nodes in the daughter edges become reentrant (before being trimmed by the *deleted-daughters* setting).

In terms of implementation, I reckon this would require keeping pointers from each edge to the AVM nodes that represent its accessible variables (or rediscovering them on the fly every time a unification succeeds).  With a Tomabechi-style unifier, you could then verify that in the temporary unification result the relevant nodes on each side got forwarded to each other.

Personally, I doubt this situation is common enough to justify the overhead -- but it would be interesting to know :-).

On Nov 29, 2013, at 2:37 PM, Spencer Rarrick <spencer.rarrick at gmail.com> wrote:

> Clearly we are missing a constraint in one or more parts of our generation pipeline. There are fixes we have thought of, but we are not sure if they would have unintended consequences and possible block some valid realizations in other circumstances:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20131130/a24e651a/attachment.html>

More information about the developers mailing list