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

Re: [lojban] Re: tersmu 0.2



* Tuesday, 2014-10-21 at 19:16 -0300 - Jorge Llambías <jjllambias@gmail.com>:

> On Mon, Oct 20, 2014 at 10:06 PM, Martin Bays <mbays@sdf.org> wrote:
> > * Saturday, 2014-10-18 at 22:27 -0300 - Jorge Llambías <jjllambias@gmail.com>:
> Not sure what I meant now. I think I meant that you couldn't do with most
> functions (i.e. lo-functions) what you could do with the closed class of
> LAhE-functions, in terms of scope. (You can do it indirectly by using the
> prenex, of course.)

Ah, I see. Then yes, na'u aside.

> > But anyway: technically the class isn't actually closed, because of {na'u}!
> 
> Would "na'u broda" be an open class of functions but not "lo broda"? "na'u"
> seems to be an inside-of-mex equivalent of "lo". We could say that "lo
> broda"="li na'u broda mo'e zo'e/zi'o".

Plausibly.

> > {ro danlu cu jbena gi'e ba bo morsi}
> "ro danlu" has scope over "gi'e" so it would be:
> 
> ro da poi danlu zo'u ge ge da jbena gi da morsi gi lo nu da morsi cu balvi
> lo nu da jbena

Good. Agreed (as far as the scope goes).

> > If the logical connective isn't {je}, probably the tag relation should
> > only apply when the connectands are both true, i.e. corresponding
> > events/facts occur/hold. This seems sensible, and is supported by CLL
> > Chapter 10 Verse 17.10.
> 
> So ".i je nai [tag] bo" is always false?

I meant rather that it would be equivalent to ".i je nai bo". 

> > Firstly, we need a way to assign an event/fact variable to a proposition
> > without changing its semantics. {fi'o du} lets us do this; {fi'o du ko'a
> > broda} means that broda occurs/holds and ko'a is equal to the
> > event/fact of this. Let's make this a primitive in the logic, writing it
> > as "=.", so e.g. "{ko'a}=. broda()". (So technically "[term]=." is
> > a modal operator.)
> 
> I had never considered "fi'o du", it sounds useful. Maybe we want "fi'o
> ca'e du" if it's an assignment to a variable, rather than a claim. Or maybe
> it should be "sei ca'e ko'a du'u no'a", although I'm not sure whether
> "no'a" gets the right bridi.

* Wednesday, 2014-10-22 at 00:30 +0200 - Ilmen <ilmen.pokebip@gmail.com>:
} I think you need {ca'e} for assigning a referent to {ko'a} (otherwise it
} would be an assertion "the bridi is identical to {ko'a}'s referent"), or
} whatever is the correct way to explicitly assign a referent to a
} pro-bridi without ambiguity.

I didn't really mean it to be an assignment in that sense, although
perhaps that could help. I did really mean that I want {fi'o du ko'a
broda} to occur/hold iff (broda occurs/holds and ko'a is the event/fact
of this).

(I think from now on I'll just say "occur" and "event"; depending on our
ontology of events, facts could just be special cases anyway - though
I don't know if we want to require that.)

} {fi'o} is maybe a little too vague for your purpose; I'd suggest {broda
} xoi <http://jbovlaste.lojban.org/dict/xoi> ke'a ca'e du fo'a} which
} would be semantically equivalent to {lo du'u broda ku ca'e du fo'a}, if
} I'm not mistaken.

Is {broda xoi xo'i [tag] ke'a} not equivalent to {[tag] broda}?

> > (I write the above paragraph as if I'm sure it makes sense, but I'm not.
> > If there are many events of brodaing in the situation, is {fi'o du ko'a
> > broda} true when ko'a is any of those events, or only when it's the
> > "intended" one?
> 
> I would say it assigns to "ko'a" the intended ones, i.e. the ones you are
> describing with this proposition.

Plurally? Yes, that's another possibility. It would make things simpler
if we took a bridi to describe to a single event for the purposes of tag
handling (though of course allowing {lo mu nu limna} and so on).
I suppose we have to allow it to describe kinds of events too, if we're
to explain {roi} compositionally ({mu roi broda} -> "brodaing occurs
five times"). But I can't think of natural example where a plural
interpretation is necessary. Probably I'm just lacking imagination?

> Then we can handle tagged conjunction by quantifying over events:
> > ro danlu cu jbena gi'e ba bo morsi ->
> >     FA x1:(danlu(_)). EX x2. (x2=. jbena(x1) /\ (ba)(x2). morsi(x1))
> >     ro da poi ke'a danlu ku'o su'o de zo'u ge fi'o du de zo'u da jbena
> >     gi ba de zo'u da morsi
> > , which is I think a natural and useful way to interpret it.
> >
> > Now for connectives other than conjunction, I'm not seeing a neater
> > solution than to "skim off" the TT case (if there is one); so e.g. to
> > consider {broda .i na ja ba bo brode} to be equivalent to
> > { na broda .i ja broda .i je ba bo brode}, where the tagged conjunction
> > is interpreted as above.
> >
> > Not very pretty. I'd be happy to hear of alternative possibilities.
> 
> The fact that it only works well with "je" suggests there's something wrong
> with the "jek tag bo" construction.

I don't know, the "TT-skimming" semantics seem to give useful results in
at least some cases.

Probably most usefully, {broda na .i ja ba bo brode} would mean "if
broda, then afterwards brode".

Then there's the {ja} case I referred to in CLL, which seems reasonable.

For {jo}, it doesn't have an easy translation to english, but seems
plausibly useful anyway; e.g. {do ba prije gi'o ja'e bo snada} -> "you
will be wise and therefore successful, or neither".

> > It's odd however to have to read "li no pi'i mo'e ro namcu cu du li no"
> > > differently than "lo pilji be li no bei ro namcu cu du li no"
> >
> > Is it? I don't know.
> >
> > To analogise: I think the english pair
> > "zero times any number is equal to zero" and
> > "the product of zero and every number is equal to zero"
> > conveys the two meanings, using roughly the same structures.
> 
> But that's purely due to the different scopes of any/every, not to the
> variation between times/product-of.  If you had "zero times every number is
> equal to zero" and "the product of zero and any number is equal to zero"
> you'd get the opposite result.

You're right for the second (a flexibility it would be nice for lojban
to have), but I think "zero times every number is equal to zero" is just
bad english; it can't have the opaque meaning. Which was my point.

Martin

Attachment: signature.asc
Description: Digital signature