Received: from mail-la0-f62.google.com ([209.85.215.62]:33834) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1YbUPg-0007gf-OZ; Fri, 27 Mar 2015 06:35:09 -0700 Received: by lams18 with SMTP id s18sf31411098lam.1; Fri, 27 Mar 2015 06:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe; bh=OVjPpeWSqny5/W41PaGjPD5GV6JXumvb3F3WZHtm5pI=; b=Apa1CECbovNjF+xJbjQBOR236h12DaKWa1IsgM5LDpxYAf/fkJLEE322pRzAz9Ce7J 3WJGQt1sz6B4Hm5SiGYIGuVLv4mA0yvO/Z7DUgq6m9fTgmobqU8FsYVDQlh4bxVG37fE Fd32dWsiDWbTrUYUtWtFhdHCugileCB7Brm9am6gsIA+lzXD5PxOfOvCNiGGavuqQ5WD A/aZj3ZpzCIlXY7ru+AgMMGw35ILQNLGvy2/Q7LdVNcYn42cGoes9DgTJnt/Z/ubyoXB oQtSTWBYGu0NzAWla4tJgzdSD2jTeHqFVHSo5pdvKfcPp3CquXAaYuppRbzP5qj0pdJi 03jQ== X-Received: by 10.152.20.169 with SMTP id o9mr311493lae.6.1427463297332; Fri, 27 Mar 2015 06:34:57 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.152.28.100 with SMTP id a4ls377128lah.23.gmail; Fri, 27 Mar 2015 06:34:56 -0700 (PDT) X-Received: by 10.112.198.34 with SMTP id iz2mr4765867lbc.22.1427463296692; Fri, 27 Mar 2015 06:34:56 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com. [2a00:1450:400c:c05::22a]) by gmr-mx.google.com with ESMTPS id i8si105046wif.1.2015.03.27.06.34.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 06:34:56 -0700 (PDT) Received-SPF: pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::22a as permitted sender) client-ip=2a00:1450:400c:c05::22a; Received: by mail-wi0-x22a.google.com with SMTP id g7so26535573wib.1 for ; Fri, 27 Mar 2015 06:34:56 -0700 (PDT) X-Received: by 10.180.94.199 with SMTP id de7mr57625792wib.53.1427463296457; Fri, 27 Mar 2015 06:34:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.240.197 with HTTP; Fri, 27 Mar 2015 06:34:35 -0700 (PDT) In-Reply-To: References: From: Gleki Arxokuna Date: Fri, 27 Mar 2015 16:34:35 +0300 Message-ID: Subject: Re: [bpfk] Improvements to fragments in ilmentufa parser To: bpfk-list@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04447e9fb7221a05124532ef X-Original-Sender: gleki.is.my.name@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::22a as permitted sender) smtp.mail=gleki.is.my.name@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: bpfk-list@googlegroups.com Precedence: list Mailing-list: list bpfk-list@googlegroups.com; contact bpfk-list+owners@googlegroups.com List-ID: X-Google-Group-Id: 972099695765 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.7 (-) X-Spam_score: -1.7 X-Spam_score_int: -16 X-Spam_bar: - --f46d04447e9fb7221a05124532ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-03-27 11:00 GMT+03:00 Gleki Arxokuna : > > > 2015-03-27 3:02 GMT+03:00 Jorge Llamb=C3=ADas : > >> >> >> On Thu, Mar 26, 2015 at 4:30 AM, Gleki Arxokuna < >> gleki.is.my.name@gmail.com> wrote: >>> >>> 2015-03-26 1:04 GMT+03:00 Jorge Llamb=C3=ADas : >>>> >>>> On Wed, Mar 25, 2015 at 6:35 AM, Gleki Arxokuna < >>>> gleki.is.my.name@gmail.com> wrote: >>>>> >>>>> >>>>> E.g. I suppose COhE_elidible should be inserted to more constructs. >>>>> but I haven't looked at where it can be done. What else apart from wh= at has >>>>> been done can be autocorrected to bridi status? >>>>> >>>> >>>> Every fragment can. For example instead of fragment "ek" you could hav= e >>>> "KOhA_elidable ek KOhA_elidable COhE.elidable", where KOhA_elidable co= uld >>>> return "ZOhE". >>>> >>> >>> Not sure I would use that. How would this work for joik? {joi} fragment >>> could be understood both as {zo'e joi zo'e co'e} and as {co'e joi co'e} >>> >> >> "joi" can't be a fragment though. The reason is that it would clash with >> the sentence connective ".i joi". Fragment is a weird rule, I would happ= ily >> remove relative clauses, links and linkargs from it. I don't think fragm= ent >> "na" is used much either. >> > > What methods do you use or want to make the development process happen > faster? > A web tool that would allow to insert a complete PEG file, compile it and > test it online? > > > >> > >> >>> Okay, then I'll add >>> fragment =3D COhE_fragment / ek free* / gihek free* / quantifier / >>> (NA_clause !JA_clause free*)+ / relative_clauses / links / linkargs >>> >>> COhE_fragment =3D prenex (terms GOhA_elidible VAU_elidible free*)* / te= rms >>> GOhA_elidible VAU_elidible free* >>> >>> sentence =3D terms? bridi_tail_t1 (joik_jek bridi_tail / joik_jek stag? >>> KE_clause free* bridi_tail KEhE_elidible free*)* / COhE_fragment >>> >>> Thus only COhE_fragment can be a sentence, and the structure of >>> COhE_fragment is limited only to {mi zo'u ca ma}, {mi ije ma} and {mi d= jica >>> lo nu lo plise}. >>> >> >> I wonder whether it wouldn't be more elegant to eliminate COhE_fragment >> and make the "selbri" of a bridi-tail elidable instead. Something like: >> >> bridi-tail-3 <- selbri? tail-terms / gek-sentence >> > > Hard for me to determine what is the cause but this breaks {mi zo'u mi mo= }. > Probably because it thinks that prenex is a selbri. 1. Anyway, I made all those test sentences work by using this: sentence =3D expr:(terms? bridi_tail_t1 (joik_jek bridi_tail / joik_jek sta= g? KE_clause free* bridi_tail KEhE_elidible free*)** / terms GOhA_elidible !ZOhU_clause*) {return _node("sentence", expr);} This tries restoring {co'e} if zo'u doesn't follow however a sentence mus have either a tail or a term to be restored otherwise it is never restored What are the minimal requirements to restore a bridi if not from terms or from bridi_tail ? Probably it can be restored from isolated {i} or {ni'o} but since this already works, then other types of restoration should be discussed separately since they don't touch anything here. 2. We could also add this if "fragment" is removed from the grammar: tanru_unit_1 =3D tanru_unit_2 linkargs? / linkargs? tanru_unit_2 */ GOhA_elidible linkargs* This makes {i be mi} parse as (i [CU {COhE } VAU]) However, selpa'i's examples don't work here. Should {noi mo} a). be restored into {noi mo cu co'e} implying {fa xi xo'e zo'e noi mo cu co'e} or b). should it instead be considered a continuation of the previous clause said by another speaker like with selpa'i's example with {be ma}? Both solutions seem reasonable. Maybe take option b). and treat a discourse split between several people as one sentence with special FUhE .. FUhO markers? mi viska lo pendo FUhE [B asks] be ma [FUhO] mi viska lo pendo FUhE [B asks] noi mo [FUhO] A: - I see a friend. B: - Of whom? A: - I see a friend. B: - Who does what? This would reformulate fragments as parts of discourse so that we can remove them from the grammar. Of course, this would require somehow preparing existing texts by marking them with those FUhE ... FUhO so that we can parse them. I also allowed relative clauses in sumti without their heads. If fragments are removed from the grammar then similar things can be useful: sumti_4 =3D expr:(sumti_5 / *relative_clauses / *gek sumti gik sumti_4) {return _node("sumti_4", expr);} This results in {fa noi pendo mi cu melbi} (in fact it may even make {be} useless except when used stylistically). > >> At some point there was talk of making the selbri of a sumti-tail >> elidable as well, so that "lo ku" would be a valid sumti. >> > I almost never use {ku} in this sense (LE-terminator). Besides, some people think that {cu} should mark the beginning of a bridi tail. In this case I don't understand how to treat {lo cu broda}. Should it be {lo COhE KU cu broda} or {lo cu broda KU CU COhE} ? P.S. This discussion becomes bulky since parts of the grammar are interconnected with a huge domino effect. Idk, maybe this is great goal (a system with tightly interconnected parts). PP.SS. This bulkiness can clearly show why Elephant will never work - no individual issues, there is only one huge issue, called "PEG Lojban". >> mu'o mi'e xorxes >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "BPFK" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bpfk-list+unsubscribe@googlegroups.com. >> To post to this group, send email to bpfk-list@googlegroups.com. >> Visit this group at http://groups.google.com/group/bpfk-list. >> For more options, visit https://groups.google.com/d/optout. >> > > --=20 You received this message because you are subscribed to the Google Groups "= BPFK" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list+unsubscribe@googlegroups.com. To post to this group, send email to bpfk-list@googlegroups.com. Visit this group at http://groups.google.com/group/bpfk-list. For more options, visit https://groups.google.com/d/optout. --f46d04447e9fb7221a05124532ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-03-27 11:00 GMT+03:00 Gleki Arxokuna <gleki.is.my.name@g= mail.com>:


2015-03-2= 7 3:02 GMT+03:00 Jorge Llamb=C3=ADas <jjllambias@gmail.com>:

On Thu, Mar 26, 2015 at 4:30 AM, Gleki Ar= xokuna <gleki.is.my.name@gmail.com> wrote:
2015-03-26 1:04 GMT+03:00 Jorge Llamb=C3=ADas &= lt;jjllambias@gma= il.com>:
On Wed, Mar 25, 2015 at 6:35 AM, G= leki Arxokuna <gleki.is.my.name@gmail.com> wrote:

E.g.=C2=A0I suppose COh= E_elidible should be inserted to more constructs. but I haven't looked = at where it can be done. What else apart from what has been done can be aut= ocorrected to bridi status?

<= div>Every fragment can. For example instead of fragment "ek" you = could have "KOhA_elidable ek KOhA_elidable COhE.elidable", where = KOhA_elidable could return "ZOhE".=C2=A0
<= /blockquote>

Not sure I would use that. How would= this work for joik? {joi} fragment could be understood both as {zo'e j= oi zo'e co'e} and as {co'e joi co'e}

"joi" can't be a fra= gment though. The reason is that it would clash with the sentence connectiv= e ".i joi". Fragment is a weird rule, I would happily remove rela= tive clauses, links and linkargs from it. I don't think fragment "= na" is used much either.

=
What methods do you use or want to make the development p= rocess happen faster?
A web tool that would allow to insert a com= plete PEG file, compile it and test it online?
<= br>

=C2=A0
=C2=A0=C2=A0
Okay,= then I'll add
fragment =3D COhE_fragment / ek free* / g= ihek free* / quantifier / (NA_clause !JA_clause free*)+ / relative_clauses = / links / linkargs

COhE_fragment =3D prenex (terms GOhA= _elidible VAU_elidible free*)* / terms GOhA_elidible VAU_elidible free*
=

sentence =3D terms? bridi_tail_t1 (joik_jek = bridi_tail / joik_jek stag? KE_clause free* bridi_tail KEhE_elidible free*)= * / COhE_fragment

Thus only COhE_fragment ca= n be a sentence, and the structure of COhE_fragment is limited only to {mi = zo'u ca ma}, {mi ije ma} and {mi djica lo nu lo plise}.

I wonder whether it wouldn&= #39;t be more elegant to eliminate COhE_fragment and make the "selbri&= quot; of a bridi-tail elidable instead. Something like:

=C2=A0bridi-tai= l-3 <- selbri? tail-terms / gek-sentence
<= /blockquote>

Hard for me to determine what is the= cause but this breaks {mi zo'u mi mo}.

Probably because it thinks that prenex is a selbri= .=C2=A0

1. Anyway, I made all those test sentences= work by using this:

sentence =3D expr:(terms? bri= di_tail_t1 (joik_jek bridi_tail / joik_jek stag? KE_clause free* bridi_tail= KEhE_elidible free*)* / terms GOhA_elidible !ZOhU_clause) {return _= node("sentence", expr);}

This tries rest= oring {co'e} if zo'u doesn't follow however a sentence mus have= either a tail or a term to be restored otherwise it is never restored

What are the minimal requirements to restore a bridi i= f not from terms or from bridi_tail ? Probably it can be restored from isol= ated {i} or {ni'o} but since this already works, then other types of re= storation should be discussed separately since they don't touch anythin= g here.


2.=C2=A0We could also add t= his if "fragment" is removed from the grammar:

tanru_unit_1 =3D tanru_unit_2 linkargs? / linkargs? tanru_unit_= 2 / GOhA_elidible linkargs

This makes= {i be mi} parse as=C2=A0(i [CU {COhE <be mi BEhO>} VAU])=C2=A0
=

However, selpa'i's examples don't work here= .

Should {noi mo} a). be restored into {noi mo cu = co'e} implying {fa xi xo'e zo'e noi mo cu co'e} or b). shou= ld it instead be considered a continuation of the previous clause said by a= nother speaker like with selpa'i's example with {be ma}?
=
Both solutions seem reasonable. Maybe take option b). and tr= eat a discourse split between several people as one sentence with special F= UhE .. FUhO markers?

mi viska lo pendo FUhE [B ask= s] be ma [FUhO]
mi viska lo pendo FUhE [B asks] noi mo [FUhO]
=

A: - I see a friend.
B: - Of whom?

A: - I see a friend.
B: - Who does what?

This would reformulate fragments as parts of discours= e so that we can remove them from the grammar. Of course, this would requir= e somehow preparing existing texts by marking them with those FUhE ... FUhO= so that we can parse them.

I also allowed relativ= e clauses in sumti without their heads. If fragments are removed from the g= rammar then similar things can be useful:

sum= ti_4 =3D expr:(sumti_5 / relative_clauses / gek sumti gik sumti_4) {= return _node("sumti_4", expr);}

Th= is results in {fa noi pendo mi cu melbi} (in fact it may even make {be} use= less except when used stylistically).



<= div class=3D"gmail_quote">

=

At some point there= was talk of making the selbri of a sumti-tail elidable as well, so that &q= uot;lo ku" would be a valid sumti.

I almost = never use {ku} in this sense (LE-terminator). Besides, some people think th= at {cu} should mark the beginning of a bridi tail. In this case I don't= understand how to treat {lo cu broda}. Should it be {lo COhE KU cu broda} = or {lo cu broda KU CU COhE} ?


P.S. = This discussion becomes bulky since parts of the grammar are interconnected= with a huge domino effect. Idk, maybe this is great goal (a system with ti= ghtly interconnected parts).
PP.SS. This bulkiness can clearly sh= ow why Elephant will never work - no individual issues, there is only one h= uge issue, called "PEG Lojban".

=

mu'o mi'e x= orxes

--
You received this message because you are subscribed to the Google Groups &= quot;BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list+unsubscribe@googlegroups.com.
To post to this group, send email to bpfk-list@googlegroups.com.
Visit this group at http://groups.google.com/group/bpfk-list.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups &= quot;BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list= +unsubscribe@googlegroups.com.
To post to this group, send email to bpfk-list@googlegroups.com.
Visit this group at ht= tp://groups.google.com/group/bpfk-list.
For more options, visit http= s://groups.google.com/d/optout.
--f46d04447e9fb7221a05124532ef--