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

Re: resolution of open Lojban issues - limited distributiuon message



>> 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