* Saturday, 2011-11-26 at 17:53 -0300 - Jorge Llambías <jjllambias@gmail.com>:
> On Sat, Nov 26, 2011 at 4:53 PM, Martin Bays <mbays@sdf.org> wrote:
> >
> > Is there any reasoning at all for the current asymmetry?
> >
> > I see no issue at all as far as the semantics goes with allowing "guhek
> > selbri-3 gik selbri-3" and "gek sumti gik sumti". In terms of my code,
> > it would involve changing two characters...
>
> I assume it had to do with how they wanted forethought to group with
> respect to afterthought.
Ah yes. It lets you grab the whole of a gek-gik in afterthought.
Well, a pretty minor issue.
> > In other words, I'm interpreting a seltau as giving an implicit
> > subsentence (complete with a prenex to export to), with linkargs
> > becoming tailterms and an analogue of {ke'a} in the x1.
> >
> > Does that seem right?
> >
> > The actual semantics of the resulting Tanru is something I "leave to the
> > pragmatics module", i.e. don't even try to handle for now. But my
> > assumption is that all the data required to interpret the tanru is
> > that I'm giving, i.e. the seltau as a unary predicate and the tertau as
> > a relation.
>
> Since you don't say anything about the resulting semantics, why do you
> need the seltau being a unary predicate rather than a relation?
Because I believe this to be what seltau are, i.e. that higher places
are filled with zo'e. Just like in description sumti.
I checked this against the uses of tanru in the CLL.
Having it be any other way would make guessing the meaning of a tanru
even more difficult than it currently is.
> My first impression would be that sometimes the pragmatics module
> might need to use the full relation implicit in the seltau rather than
> just the forced unary predicate.
Hrm. I hope not.
> >> If you have "su'o da" with scope over "gi'e", there is no doubt that
> >> it will also have scope over "na".
> >
> > Actually... no, that isn't how I'm doing it. I have the extra tail terms
> > after the vau distributing over the gi'e conjuncts, appending the tail
> > terms to each, and the result then being interpreted:
> >
> > na broda gi'e na brode vau da
> > -> na broda da gi'e na brode da
> > -> EX x. [ na broda x gi'e na brode x ]
> > -> EX x. (!broda(x) /\ !brode(x))
>
> Yuck. So you distribute the *text* "da", and only then consider the
> implicit quantifier?
Not literally the text, but a purely syntactic proxy for it (so 'yuck'
is still a reasonable reaction).
But isn't this how you would handle tailterms when converting to a gek?
I suppose your point is that this leads to less objectionable results.
I can't deny that there's something fairly horrible about {broda gi'e
brode vau na ku} ending up as equivalent to {broda gi'e brode}...
I see one other possible approach: interpret the connected tail terms of
a connected briditail once, but have any resulting sumti be appended to
both bridi. That would sole the {vau na ku} and {vau PA da} uglinesses,
and I don't see any theoretical problems with it. It would, however,
complicate the code quite a bit, suggesting that it isn't very natural.
So... OK, you win.
I'm now handling giheks analogously to eks, giving e.g.
broda da de gi'e brode vau de na ku di
== ge broda da de gi brode vau de na ku di
== (EX x1. EX x2. !EX x3. broda( ,x1,x2,x2,x3) /\
EX x1. !EX x2. brode( ,x1,x2)) .
Thanks.
> Does that mean you get a different result for:
>
> na broda gi'e na brode vau su'o da
As it happens I didn't, but only because I have {ny da my da} equivalent
to {ny da da} - because I couldn't make any sense of the CLL's
prescriptions for quantifiers on already bound {da}.
Any advice on that?
Martin
Attachment:
pgpxSZLiMEBhn.pgp
Description: PGP signature