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

[Spencer Rarrick]

Re: fixed-aritiness per pred, if you look at core.smi for the erg, there
are quite a few preds listed here with "optional" arguments. (At least that
is what I assume "[...]" means around an argument position, and it is
consistent with the behavior seen with "_look_v_1_rel".)  I'm not entirely
certain under what the criteria are for using optional arguments vs
creating a new pred for a particular form.  Perhaps there is some sort of
"implied" argument in cases where an optional argument is omitted?
However, there seems to be some inconsistency here (or perhaps a
consistency that I don't fully understand), as none of the arguments on
"_exaggerate_v_1_rel", "_eat_v_1_rel" or "_drink_v_1_rel" are optional
(they always have ARG0, ARG1 and ARG2), but ARG2 on "_look_v_1_rel" is
optional, and the different arity versions appear on "look_v1" and
"look_v4".  Any ideas what may be going on here?

Spencer




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

> > once we have unexpressed arguments, i would think there
> > is no formal difference between [ ..., ARGn u, ... ] vs. just no
> > mention of that ARGn role, or?
>
> On the contrary, a formal difference is exactly what there is.  It may
> well be that by interpretation you mean to assign no difference in truth
> conditions (or whatever else) to those predicates, but their *form* is
> certainly different.
>
> On Francis's point, I believe he meant to recall the point that predicates
> in the underlying logical language are presumably fixed arity, and having
> multiple MRS-level predicates with the same name but different arities (or
> argument types) is opening the door to confusion (as for example happened
> when Agree was confused, starting this thread).  I will readily agree that
> being able to underspecify between target-language predicates may be a
> useful bit of functionality; however, the problem here seems perhaps to be
> *unintentional* underspecification.
>
> That brings up the related question of what the logical status of a "u"
> variable is?
>
> Woodley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20131202/f2d041a5/attachment.html>