[YG Conlang Archives] > [engelang group] > messages [Date Index] [Thread Index] >


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

Re: [engelang] Logos Initiative



Jorge Llamb�as jjllambias@hidden.email [engelang], On 02/10/2014 01:40:
On Wed, Oct 1, 2014 at 9:00 PM, And Rosta and.rosta@hidden.email <mailto:and.rosta@hidden.email> [engelang] <engelang@yahoogroups.com <mailto:engelang@yahoogroups.com>> wrote:
    Jorge Llamb�as jjllambias@hidden.email <mailto:jjllambias@hidden.email> [engelang], On 02/10/2014 00:13:
    > I was thinking about this last part and I can't figure out a way of
    > doing "red door and blue doorknob" with just the four predicates. Is
    > there some sort of restriction that prevents the use of the two
    > merger types on the same virtual list item?

    I suspect I've not understood your question, so let me just give you a work through of that phrase:

    1. Add Red1 to vlist
    2. Intersective-merge Red1+Door1, leave on vlist
    3. Add Blue1 to vlist
    4. Intersective-merge Blue1+Doorknob1, leave on vlist
    5. Additive merge Red1+Door1 & Blue1+Doorknob1 (leave on/remove from vlist)

    Step 5 would be marked as an inflection within the word with stem Doorknob, following the inflection corresponding to Step 4.

Ah, ok, that makes sense now. I didn't realize you could have more
than one inflection in the same word and for the same ESAP.

I had originally intended expositorily only a broad-brush indication of the general strategy, rather than a full outline of the specifics of Livagian.

I guess a word's ESAP can also merge with another ESAP from the same
word that has been previously added to the vlist, to get reflexives
in the case of intersective merge, or things like "brothers" for
additive merge?

With regard to reflexives, in principle you're right, but in practice I've vacillated. The downside to handling reflexives just like any other merger are at least twofold. Firstly it leads to a lot of in effect wasted inflectional space, because there would be ordinary inflectional ways to encode every conceivable merger among arguments of the same predicate, and almost all of those will either be utterly nonsensical or express a pretty-much=never-needed meaning. Second, although the way I formulated the list of steps for the basic process allows reflexive merger, it means that if each item on the vlist is visible to the incoming ESAP, then it means that "showing which item on the vlist the incoming ESAP merges with" must count back even through vlist items that have come from the incoming predicate. Because that -- reflexivity -- is so much the exception rather than the norm, the actual basic rules are that the incoming ESAP can see only vlist items that don't come from the same pr
edicate; this requires less counting. ("Showing which item on the vlist the incoming ESAP merges with" involves counting; in current Livagian, items are in the order they first get added to the vlist, and counting starts from the most recently added item (ignoring any items that are from the same predicate as the incoming ESAP). So to actually do reflexives I've used two solutions. One is to use an extra predicate like Lojban {du}, so that "X loves X" gets rendered as "X loves Y & X du Y". This, incidentally, is the strategy I use for so-called 2D-Livagian notation of predicate logic, where the notation can't handle reflexivity. The other solution is to use special inflections that augment a stem to reflexivize it; these inflections would augment the inflection that shows the predicate's adicity and how many ESAPs it has. In 2014 Livagian I use this latter method, at least for predicates of maximal tetradic adicity (including event arg, which can't be inflectionally marked as reflexi
ve).

As for additive merger, the particular case of "brothers" is unlikely to arise, because rather than having symmetric predicates like "X is brother of Y", I tend to use the "X joi Y are brothers" method. But something like "mother and child (are well)" (i.e. "X is mother of Y, X joi Y are well") can arise, and iirc it works by making every item on the vlist visible to an additively-merged incoming ESAP.

There are still more complications in that you can get cycles of alternate additive and intersective merger involving the same incoming ESAP. For example, "xorxes joi And discuss" might have a word order "discuss, xorxes, And", such that -- ignoring event arguments -- there is a vlist <Discuss1, xorxes1> and so first And1 additively merges with xorxes1, and then the result, And1&xorxes1 intersectively merges with Discuss1. And if the phrase were "Obama and discussants xorxes and And", with word order "Obama, discuss, xorxes, And", (And1&xorxes1)+Discuss1 would additively merge with Obama1, yielding ((And1&xorxes1)+Discuss1)&Obama1. I currently require that the counting for this iterative process be successive, so that each new merger, of the same ESAP, involves counting back from the vlist position of the previous merger, not from the end of the list all over again. This is the one respect in which predicate order is not free, because predicates must occur in an order that matches i
terated merging. As I write this paragraph I realize that in principle (tho improbable), you could have two distinct iterated merger sequences involving the same predicates but each requiring the predicates to be in a different sequence -- which means I am going to have to rethink my solution to this bit.

--And.