[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] semantic parser - tersmu-0.1rc1



* Thursday, 2011-12-08 at 13:48 -0300 - Jorge Llambías <jjllambias@gmail.com>:

> A somewhat separate issue is what to do with apparently unbound
> variables. The basic rule is:
> 
> (4) Ex:P(x)  <--->  P(x)
> 
> but again this is underspecified as to the order in which it has to be
> applied with respect to the other rules. If you want to unpack
> P(Ax,y), you get something different if you apply (1) and then (4), or
> if you apply (4) first and then (1).
> 
> My preferred rule is that whenever you run into a variable x which is
> apparently unbound, it gets replaced by Ex, so P(x) must be read as
> P(Ex) and only then apply the unpacking rules 1, 2 and 3 in the order
> described above. But even better is to never omit the explicit
> quantifier.

If you'll excuse me tangling this thread...

It occurs to me that this indicates a simple description of the
difference between the two possible rules we were discussing for
handling bare {da} after a da-binding connective. They both have us, as
you say, replacing x by Ex whenever we run into an apparently unbound
x - the difference is just in when they run into it.

In the case of {ro da .e ko'a da}: under one rule (I) the connective causes
us to *fork*, and process the remainder of the sentence in two different
parallel contexts, so the bare {da} is run into *twice*.

For the other (II), I see two ways to imagine (and code) it: either
(a) we have a preprocessing stage which statically observes that the
bare {da} isn't going to be properly bound so adds a {su'o} to it, and
then we process as above; or
(b) we have no such preprocessing stage, but nor do we really fork in
the sense above - rather, once the connective is complete subsequent
terms are seen but once, and are applied to both arms of the connective.

(Please note that in both cases, I am assuming that all referring
constant terms do their referring prior to this algorithm; the forking
doesn't involve textual reduplication)

I do still find (I) the most conceptually intuitive, although the
results of (II) may be cleaner.

Martin

Attachment: pgpzjMHD34Fla.pgp
Description: PGP signature