Re: resolution of open Lojban issues - limited distributiuon message
Veijo Vilva
linkchains using BO as an terminator - BO cannot anymore, of course,
be used as glue. I also corrected an oversight in the previous verson.
In an otherwise unmodified grammar (the old rules for termsets can be
removed, however):
terms_80 : term_81a
| terms_80 term_81a
;
term_81a : term_81
| GEK_807 term_81 links_161 GIK_816 term_81 links_161
;
term_81 : sumti_90
| modifier_82
| GEK_807 term_81 links_161
GIK_816 term_81 links_161 BO_508
| NA_KU_810
;
The forethought termset is included twice, once without and once
with a terminator. BEI cannot be used as glue within modifiers, the
glue used for termsets and the glue used for modheads must be
different - so it is either ce'e or noi for the modheads.
Veijo
Veijo Vilva
Putting it all together:
terms_80 : term_81a
| terms_80 term_81
;
term_81a : term_81
| GEK_807 term_81 links_161 GIK_816 term_81 links_161
;
term_81 : sumti_mod_chain_82
| GEK_807 term_81 links_161
GIK_816 term_81 links_161 BO_508
| NA_KU_810
;
sumti_mod_chain_82 : sumti_or_mod_84
| sumti_mod_chain_82 CEhE_680 sumti_or_mod_84
;
sumti_or_mod_84 : sumti_90
| mod_head_490 gap_450
| mod_head_490 sumti_90
| mod_head_490 CEhE_680 selbri_130 tail_terms_71
;
Notes:
1) there is no possibility of grouping within a chain
2) The last rule for sumti_or_mod_84 makes terms like "zace'e nanca
lire" possible. VAU is required at the end of tail_terms if the
chain continues. "vau ce'e" can only be avoided by adding a new
cmavo (ce'u ?). distance+refpoint could then be expressed as
follows:
vace'e mitre limu ce'u le vorme
The added rule would be:
| mod_head_490 CEhE_680 selbri_130 tail_terms_71
CEhU_681 sumti_90
This would give the shortest possible expression for the most
common case. An added bonus is that a following ce'e doesn't
tie to the sumti but to the whole phrase.
I'm ready to buy this model in case you still don't buy a limited relative
clause model with NOI_585 replacing CEhE_680 in the last rule.
I think, however, that a rule of either type is the only Zipfean solution
-- anything building on a sumti structure adds unnecessary complexity.
Veijo
Logical Language Group
>> She says that you are strongly for the phrasal short scope sentence "i".
>--More--
>> I have said that I support this, especially if you set up an appropriate
>> grammar chain for it so it does not include the broken sentences that
>> the mainline grammar supports. To make this work, you end up needing a
>> cmavo to serve as "i" does, or to mark and "i" as phrasal. I like just
>> having a separate cmavo, because then the YACC grammar is more
>> straightforward - you need not worry about s/r errors with the main
>> grammar.
>
> Could you describe the purpose of this in a few words?
I had thought the prupose of phrasal .i was mostly to allow proper scoping
of prenexes in after thought. We had long said that .ije was an expansion
gi'e, and equivalent to ge ... gi ..., and this means that quantified
variables after the "je" are bound under the prenex of the first sentence
unless otherwise overridden. But .i" and .ije have identical YACC gramamrs
and this leads to confusion.
Cowan has come up with a proper solution to this, separating the ",i" from the ".ije" grammar, and is calling it 2.45. We had previously thought separating
the two was impossible, but I guess he finally figured out a way, perhaps as
a result of doing the cleanup from the errors the EBNF analyst found. This
renders that aspect of a phrasal "i" moot.
The second aspect of phrasal "i" is to allow compound sentences inside relative
clauses and other places in the grammar where "sentence" of "bridi" is a
component. This is logical since you can put a GIhEk or GEk sentence in the
relative clause, and would merely allow the afterthought alternative. It
is not necessary, and we have incomplete coverage of after thought, so
Cowan withdraws the idea for a phrasal "i" pre-baseline as requiring too much
thought and explanation.
>> If phrasals are added, we need to consider adding them not only in the
>> mainline sentence grammar, but in the restricted sentences used by SEI,
>> NAhU, NIhE, and FIhO. All of these things, as far as I know, are really
>> supposed to be dealing with sentences or full bridi, but were
>> constrained for YACC or terminator reasons. Regularizing what is
>> permitted in these restricted sentences (but bearing in mind that they
>> haven't been allowed tail-terms to make terminators more likely to be
>> elidable) should be considered. See also discussion of FIhO in C. below
>> on this issue.
>
> I'm for regularizing.
Cowan and I talked tonight since he cannot easily post when at his country
house, and he did not address the regularizing. I presume it can be
separated from the withdrawn phrasal sentence link proposal.
>> B.
>>
>> Nora says that you talked about ro requiring existence. She favors and
>> I concur, that the default quantifiers of "lo" be whatever formulation
>> we come up with for "all without existence". pc has said something about
>--More--
>> simply eliminating default quantification, and that seems like a copout.
>> But defining that ro broda means "if da broda then roda poi broda", and
>> if noda broda then some equivalent possible-world-creating formulation
>> where brodas exist. I think that she said that you talked about 2 kinds
>> of prenex - one world-creating and the world-restricting. This
>> distinction seems well expressible through da'i/da'inai attached to the
>> sentence level or to zo'u of the prenex.
>
> I agree.
Cowan was not sure he was satisfied with this, and didn't want to think
about it tonight %^). The whole question about world-creating/restricting
is probably something that needs to be looked atby someone who has mastered
McCawley's comments on modal logic, which pc has and Cowan and I have not.
Unfortunately TLI HAS tackled this problem and come up with a proposal, though they are not yet implementing it. But we can;t play games with a baseline
coming up. I presume that most modal logic things can be handled by SOME
kind of discursive rather than a formal grammar change. But maybe I am
merely hoping. There also may be a fi'o predicate solution if a tense-based
solutuon is found.
But whatever - we aren;t going to solve this one before the book is done unless
someone gets sudden inspiration.
>> suggesting that we use CEhE/ce'e instead of BO
>>
>> The ce'e has overtones to me of a set linkage making this seem a kind of
>> termset. At which point, I would like to see if this can be merged with
>> the existing termset construction, where we would use a termset-linking
>> ce instead of addding ce'e. This might not even need a grammar change,
>> or it could be a minimal one. I will leave that for you and Veijo to
>> explore, since I think that if you do so, you could come up with a
>> lighter termset construction - Veijo's effort accomplishes much the same
>> as termsets, but without the repeated cmavo which my sloppy knowledge of
>> YACC required me to use in creating the current termset grammar.)
>
> I'll need a couple of days to ponder.
Cowan and I observe that the current termset grammar is a forethought termset,
whereas what Veijo has come up with is an afterthought termset. There is
justification to have both in the language, but it would be nice if we could
have both kinds of termsets able to take logical connectives at least as
an option if we are going to call Veijo's struture an "afterthought termset"
(which would be useful from the explanation standpoint in the book).
The usage in tenses is merely to tie terms together, and that is also the
usage in most [sa]
The usage in TERMSETS i merely to tie terms together, and that is the purpose
of the new construct. Hey, wait a minute. That may be the answer.
>term_set_83 : NUhI_587 GEK_807 terms_80 NUhU_gap_460
> GIK_816 terms_80 NUhU_gap_460
> | NUhI_587 terms_80 NUhU_gap_460
> JOIK_EK_421 terms_80 NUhU_gap_460
> ;
I have long disliked the NUhU_gap before the connective, since it does not
actually terminate anything, and is really more a cheat to avoid having
a whole new set of logical connectives. It might work to use the clumped
sumti of the new construct instead of terms_80. Naw, that won't
eliminate the NUhU_gap. ambiguous when you get to the JOIK_EK.
I'll shut up and let the better YACCers look at this one.
> I tried to find a formulation where I could link 'masti lixa', the
> simplest possible structure, to the preceding mod_head. I went through
> the cmavo list and the grammar testing various alternatives, and the
> 'za noi masti lixa' structure seemed the most natural - and Goran also
> seemed to find it intuitive.
Cowan has a proposal in the form of a new member of KI that would mark the
sumti as a quantity specifying the maginitude of the last tense term.
He pointed out that my la'u solution is not general enough (though it can
be useful) in that one might have more than one magnitude to define for a
tense complex: ZI/ZA/ZU and VI/VA/VA and the intervals and perhaps others
all might need magnitudes, and if all are present in the tense, sela'u does
not resilve which.
I'll let him explain it and give examples, but from his phone ddescription
I am inclined to support it. Itstill needs Veijo's afterthough termset
to allow all flexibility, and that construct still is useful for the
sepi'o/tepi'o linking.
> YACC will handle anything between FIhO and FEhU, it is more a question
> of agreeing with BAI. '| mod_head FIhO sentence FEhU' can be added as
> an alternative to my intmed grammar without s/r conflicts. So it is
> just a question of agreeing on what to allow within FIhO...FEhU, and
> what is the semantics.
Uniformity and the desire to minimize terminators would suggest that it be
limited tothe same thing that can be used for SEI ... SEhU. If you have
trailing sumti not joined with be/bei, then without a terminator it
swallows up the sumti you are trying to label with the FIhO (though it
culd be argued that if you are going to use a FIhO construct, you would just
appropriately embed the tagged sumti in the FIhO sentence. But even with
this you would need a KU to not have the FIhO swallow up any following
sentences.
I don't understand "mod_head FIhO sentence FEhU" since "FIhO sentence FEhU"
would BE a mod_head. It is part of rule 815 that we would be adding
alternative structures for FIhO.
So I like keeping the regularization to that ofthe 3 SEI constructs in
>discursive_bridi_34 : SEI_440 selbri_130 SEhU_gap_459
> | SOI_602 sumti_90 SEhU_gap_459
> | SOI_602 sumti_90 sumti_90 SEhU_gap_459
> | SEI_440 terms_80 front_gap_451
> selbri_130 SEhU_gap_459
> | SEI_440 terms_80 selbri_130 SEhU_gap_459
> ;
for all of the cmavo I listed as needing regularization.
HEY. As an alternative to another member of KI, John may want to look at
another member of SOI to add magnitudes. Just an idea, and I am not
going to think it out since I don't know the examples he has in mind for
his KI idea.
>> I have the nagging suspicion that the ordinal ROI may better be taken
>> care of using something other than ROI, and involving these new sumti
>> tcita constructs, since the talk about the ordinal occurance of
>> something you implicitly need some other tcita sumti to give the
>> ordering rule. Or maybe ROI can be used WITH the new construct.
>--More--
>
> I'll have to think about this.
Cowan thinks that the examples with ordinal ROI will turn out to be bogus as
"ROI" constructs, so we need to dig out Jorge's proposal.
This may not be easy %^(. I have one place where it might be easy to locate;
otherwise it is a full archive search for me.
>> Does this make any sense? Have I managed to understand (or at least
>> correctly use) lambda intuitively even if I can't make hide nor hair of
>> any formal explanation of it? (in which case I have a slight confidence
>> that it can be taught to the average ignoramus-Lojbani on the street, a
>> confidence I have been sorely lacking).
>>
>> If this makes sense, does it have anything to do with context leaping???
>>
>> %^)
>
> I'll keep out of this mess :-)
Cowan says he thinks it makes sense though it is a new application of lambda.
pc may need to comment on this.
lojbab
Logical Language Group
>About termsets:
>
> Termsets can be eliminated from the YACC grammar if we adopt
> some kind of sumti glue along the lines of my intmed grammar.
> The glue is marked with bo in the following schema:
>
> nu'i sumti sumti nu'u .e sumti sumti nu'u
> => sumti bo sumti .e sumti bo sumti
>
> nu'i ge sumti sumti nu'u gi sumti sumti nu'u
> => ge sumti bo sumti gi sumti bo sumti
>
> The glue would carry no semantic value.
It doesn't eliminate temrsets, but it might eliminate the need
for the bracketing nu'i/nu'us. There is no construct that allows
"term" as opposed to "sumti" inside a logical connective, and indeed
GEKed sumti are down in the middle of the sumti grammar at rule 93.
>>About termsets 2:
>>
>>BEI can be used as glue at the terms level. So if we exclude termsets
>>from within tanru linkargs, we get a rather regular system: termsets
>>would use bei just like linkargs do.
>>
>>terms_80 : term_81
>> | terms_80 term_81
>> | terms_80 BEI_505 term_81
>> ;
>>
>> mi klama le zarci bei le briju .e le zdani bei le ckule
>
>It would be nice, but I think we need tanru termsets, if for no othe
>r
>reason than tanru being used in SEI/FIhO constructs. But then I cannot
>think of too many places where you would want termsets in such things, and
>you could always include them before the selbri.
No strong feelings, but this really requires others besides me to think about.
Reusing existing constructs is nice, but I am of course resistent to
overload as in the case of Jorge's ke'a. Indeed, i still prefer adding
ce'e instead of using BO for the sumti link in whatever termset grammar we end
up with.
I will run these by Nora, though.
lojbab
Logical Language Group
>
> After some more thought I think the following will work -- but for
> forethought connected termsets only:
Which is what we have now.
>terms_80 : term_81
> | terms_80 term_81
> | term_81 links_161
> | GEK_807 term_81 links_161 GIK_816 term_81
>links_161
> ;
Again, I will wait to see what Cowan, pc (John starts getting ambiguous
even in this limited group %^), and Nora say. If we reach some consensus,
we can go to the list for comment.
Unless there is a forethought JOIK somewhere in the works, we would lose JOIK
termsets.
I like eliminating the special termset words and simplifying the grammar
but this may be too complicated to make sure we aren't leaving holes.
lojbab
Logical Language Group
>term_81 : sumti_90
> | modifier_82
> | GEK_807 term_81 links_161
> | NA_KU_810
> ;
>
>The forethought termset is included twice, once without and once
>with a terminator
I don't think this one is acceptable, since it means that BO is a terminator
and not a link. You could have all sumti in a sentence separates by BO
if they happen to be GEKked sumti, and you can have a GEKked sumti followed
by BO CU before the selbri, or have BO at the end of the sentence. That
is counter to all other uses of BO. Really, you just want an elidable
terminator to replace the BO in term_81, and I think your term_81a goes away.
But this still leaves the question unanswered regarding JOIK and other
connections that are permitted by NUhI, but are not defined under GEKs
lojbab
Veijo Vilva
> >term_81 : sumti_90
> > | modifier_82
> > | GEK_807 term_81 links_161
> > GIK_816 term_81 links_161 BO_508
> > | NA_KU_810
> > ;
> >
> >The forethought termset is included twice, once without and once
> >with a terminator
>
> I don't think this one is acceptable, since it means that BO is a terminator
> and not a link. You could have all sumti in a sentence separates by BO
> if they happen to be GEKked sumti, and you can have a GEKked sumti followed
> by BO CU before the selbri, or have BO at the end of the sentence. That
> is counter to all other uses of BO. Really, you just want an elidable
> terminator to replace the BO in term_81, and I think your term_81a goes away.
Agreed.
> But this still leaves the question unanswered regarding JOIK and other
> connections that are permitted by NUhI, but are not defined under GEKs
>
If we use a terminator, we can handle the JOIKs in forethought
_outside_ tanru linkargs, but the only way of doing it inside is
to use something else instead of BEI to link the terms. The only way
to avoid a terminator is to do the glueing somewhere below sumti_C_93,
which restricts the glued terms to being rather simple sumti. This
would also require a new cmavo.
> lojbab
>
Veijo