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

[Spencer Rarrick]

Woodley, thanks for the clever idea. This seems like it should fix the
problem, but I agree that it is probably not common enough to justify
impelentation costs right now, so we will likely rely on the subsumption
check for the mean time.


On Sat, Nov 30, 2013 at 4:52 PM, Woodley Packard <sweaglesw at sweaglesw.org>wrote:

> 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 :-).
> -Woodley
>
> 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/20131202/d6c691d7/attachment.html>