Received: from mail-wi0-f192.google.com ([209.85.212.192]:33147) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1Ybulf-0003d4-L5; Sat, 28 Mar 2015 10:43:33 -0700 Received: by wiwh11 with SMTP id h11sf16558198wiw.0; Sat, 28 Mar 2015 10:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from: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=3gH8H9Bp9PE2+8pmqq8al2Aut0gZaUTl6bmFDTGmRH0=; b=c4WnqBn63QR3JOJmfn4AOzgpv+Q+aCZgPVyJLrduT/Y8oTu+CIY2fQUL7P2mu4dn25 TqsjVjAq8XCuabNCkZIQhLwOuqy54jqM35QIp7cgo/j0XlWApz+tASq4pUuTiq1VEIrM N3qwZaA+/kXiAqv9ILr2ODrKx5546T2q6ipHDOg3pwH3drY0C/Hwf5nFFi7eKzwckhK0 iPaj4LObJEkN0xfOf1Z2wL9hbskUL0T704gi/8OyMRTK27+r/utXa3BsT7hfSVxMRZQK 5ThMG/Q4QVS1cmMwAvC0UqrXdRvluLsMLJdp1i7PnXgqPCEUyIpX08u+a6vITBPCTDvC PnBg== X-Received: by 10.152.5.199 with SMTP id u7mr369246lau.35.1427564604457; Sat, 28 Mar 2015 10:43:24 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.152.4.131 with SMTP id k3ls486138lak.21.gmail; Sat, 28 Mar 2015 10:43:24 -0700 (PDT) X-Received: by 10.112.25.7 with SMTP id y7mr5895123lbf.21.1427564603982; Sat, 28 Mar 2015 10:43:23 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com. [2a00:1450:400c:c00::232]) by gmr-mx.google.com with ESMTPS id c8si515675wiw.1.2015.03.28.10.43.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 10:43:23 -0700 (PDT) Received-SPF: pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:400c:c00::232 as permitted sender) client-ip=2a00:1450:400c:c00::232; Received: by mail-wg0-x232.google.com with SMTP id m6so130020401wgd.2 for ; Sat, 28 Mar 2015 10:43:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.94.199 with SMTP id de7mr7624595wib.53.1427564603845; Sat, 28 Mar 2015 10:43:23 -0700 (PDT) Received: by 10.27.86.219 with HTTP; Sat, 28 Mar 2015 10:43:23 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Mar 2015 14:43:23 -0300 Message-ID: Subject: Re: [bpfk] Improvements to fragments in ilmentufa parser From: =?UTF-8?Q?Jorge_Llamb=C3=ADas?= To: bpfk-list@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04447e9f1b333405125cc93a X-Original-Sender: jjllambias@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:400c:c00::232 as permitted sender) smtp.mail=jjllambias@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.6 (-) X-Spam_score: -1.6 X-Spam_score_int: -15 X-Spam_bar: - --f46d04447e9f1b333405125cc93a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2015 at 4:05 AM, Gleki Arxokuna wrote: > > 2015-03-28 1:21 GMT+03:00 Jorge Llamb=C3=ADas : >> >> >> I missed the part where "noi mo cu co'e" became grammatical. >> > > It has two possible explanations: > a). It means {zo'e noi mo cu co'e} > b). It is continues by one speaker a sumti said by another speaker > OK, but (b) seems to be part of a pre-parser interpretation strategy, that has to decide whether a given string is to be fed as is to the parser or needs to be first concatenated with some other string before being fed to the parser. I don't see how PEG can handle that pre-parsing stage. (b) seems to be about what to feed the parser as input rather than about what the parser should output given some input. > sumti_4 =3D expr:(sumti_5 / *relative_clauses / *gek sumti gik sumti_4) >>> {return _node("sumti_4", expr);} >>> >> >> This could be dangerous, as it makes "ta prenu poi do sisku" grammatical= , >> but not with the expected meaning. >> > > I don't know what is the expected meaning here. > Something like "ta me lo prenu poi do sisku", a relatively frequent error, I think. It can be restored to {ta prenu zo'e poi do sisku ke'a} or instead to > something like {fasnu fa lo nu ta prenu poi do sisku ke'a} or instead as > {lo ta prenu poi do sisku ke'a cu co'e}. > Did you mean "fasnu fa lo nu ta prenu _kei_ poi do sisku ke'a"? Otherwise you just have the same original "pa prenu poi do sisku" inside a "nu". But I'm confused how you would get either of those two from "ta prenu poi do sisku" where "poi do sisku" occupies an argument slot of "prenu". Is the stand-alone relative clause to be taken as an ordinary sumti or not? If yes, isn't it just filling the (potential) second slot of "prenu"? Wouldn't "mi citka poi plise" mean that I eat an apple? > Also things lika {da poi prenu ku'o noi melbi". >> > > How is this supposed to parse according to you? I can see it again either > as restoring {zo'e} or {fasnu fa lo nu} or as {lo da poi prenu ku'o noi > ke'a melbi cu co'e}. > With your proposed sumti rule, I would understand it as two sumti. I'm saying that's confusing, because it looks like a single sumti with two relative clauses. I think it's safer to require a "lo" for bare relative clauses: "lo noi >> pendo cu melbi" (this was also discussed as a good alternative to "poi'i= " >> in many cases). >> > This is related to split sumti like {fa lo gerku fa noi pendo mi cu bajra= } > where instead of {fa lo gerku} you have {fa zo'e}. > I guess what I'm saying is that relative-clauses feel more like selbri than like sumti to me, so that using them bare as sumti feels weird. I would expect "fa lo gerku fa lo noi pendo mi cu bajra", not "fa lo gerku fa noi pendo mi cu bajra". As for you suggestion it's a continuation of the official {lo noi pendo > ja'a melbi cu co'e} so it requires separate commits (do you have ideas > where to patch the peg, btw?) > Maybe something like: sumti-tail-1 <- quantifier sumti / quantifier? selbri? relative-clauses? I haven't thought out all the ramifications, but this should allow things like "ro poi broda gi'e brode cu brodi" and "lo ci cu broda". The main problem for me now is that COhE that I showed earlier is not a > true bridi_tail_t1. If you make bridi_tail_t1 elidible then it won't show > up in the output. However, in camxes.js COhE does return a "COhE", not a > node: > GOhA_elidible =3D expr:(GOhA_clause?) {return (expr =3D=3D "") ? ["COhE"]= : > _node("COhE", expr);} > > I could copy the whole bridi_tail_t1 with all (!) dependent strings > like bridi_tail_t2 etc. only in order to inject a COhE_elidible instead o= f > "selbri" in bridi_tail_3. However, we should be fighting copy pasting, > shouldn't we? > I don't have a full grasp of how the javascript works, but isn't it always possible, for any elidable rule, to make the elision "visible" in the output by replacing "rule?" with "rule / rule_elided" and making "rule_elided" absorb nothing and return whatever you want it to return? I'd also like to show ZOhE in x1 of {i broda mi} since we assume that if a > selbri has x2 it must have x1. Again the same question applies: how to > restore it without copying the whole "terms" part of the grammar? > This is not so clear to me. How would PEG know that x2 is filled? Having non-empty tail-terms is no guarantee that x2 gets filled. mu'o mi'e xorxes --=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. --f46d04447e9f1b333405125cc93a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Mar 28, 2015 at 4:05 AM, Gleki Arxokuna <gleki.is.my.name= @gmail.com> wrote:
2015-03-28 1:= 21 GMT+03:00 Jorge Llamb=C3=ADas <jjllambias@gmail.com>:<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

I missed the part where "= noi mo cu co'e" became grammatical.

It has two possible explanations:
a). It means {zo'e noi mo cu co'e}=C2=A0
b). It is cont= inues by one speaker a sumti said by another speaker

OK, but (b) seems to be part of a pre-par= ser interpretation strategy, that has to decide whether a given string is t= o be fed as is to the parser or needs to be first concatenated with some ot= her string before being fed to the parser. I don't see how PEG can hand= le that pre-parsing stage. (b) seems to be about what to feed the parser as= input rather than about what the parser should output given some input.
=C2=A0
sumti_4 =3D expr:(sumti_5 / relative_clauses / gek = sumti gik sumti_4) {return _node("sumti_4", expr);}

This could be dange= rous, as it makes "ta prenu poi do sisku" grammatical, but not wi= th the expected meaning.

I don't know what is the expected meaning here.

Something like "ta me l= o prenu poi do sisku", a relatively frequent error, I think.

It can be restored to {ta prenu zo'e poi d= o sisku ke'a} or instead to something like {fasnu fa lo nu ta prenu poi= do sisku ke'a} or instead as {lo ta prenu poi do sisku ke'a cu co&= #39;e}.

Did you mea= n "fasnu fa lo nu ta prenu _kei_ poi do sisku ke'a"? Otherwis= e you just have the same original "pa prenu poi do sisku" inside = a "nu".

But I'm confused how you= would get either of those two from "ta prenu poi do sisku" where= "poi do sisku" occupies an argument slot of "prenu". I= s the stand-alone relative clause to be taken as an ordinary sumti or not? = If yes, isn't it just filling the (potential) second slot of "pren= u"? Wouldn't "mi citka poi plise" mean that I eat an app= le?
=C2=A0
=
Also things lika {da poi prenu ku'o noi melbi".

How is this supposed to pars= e according to you? I can see it again either as restoring {zo'e} or {f= asnu fa lo nu} or as {lo da poi prenu ku'o noi ke'a melbi cu co'= ;e}.

With your prop= osed sumti rule, I would understand it as two sumti. I'm saying that= 9;s confusing, because it looks like a single sumti with two relative claus= es.=C2=A0

<= div>I think it's safer to require a "lo" for bare relative cl= auses: "lo noi pendo cu melbi" (this was also discussed as a good= alternative to "poi'i" in many cases).
=
This is related to split sumti like {fa lo g= erku fa noi pendo mi cu bajra} where instead of {fa lo gerku} you have {fa = zo'e}.

I guess = what I'm saying is that relative-clauses feel more like selbri than lik= e sumti to me, so that using them bare as sumti feels weird. I would expect= =C2=A0"fa lo gerku fa lo noi pendo mi cu bajra", not "fa lo= gerku fa noi pendo mi cu bajra".=C2=A0

As for you suggestion it's a continuation of the official {lo n= oi pendo ja'a melbi cu co'e} so it requires separate commits (do yo= u have ideas where to patch the peg, btw?)

Maybe=C2=A0something like:= 
  sumti-tail-1 <-=C2=A0quantifier sumti / quantifier? selbri? relat=
ive-clauses?
I haven't thought ou=
t all the ramifications, but this should allow things like "ro poi bro=
da gi'e brode cu brodi" and "lo ci cu broda".

The ma=
in problem for me now is that COhE that I showed earlier is not a true brid=
i_tail_t1. If you make bridi_tail_t1 elidible then it won't show up in =
the output. However, in camxes.js COhE does return a "COhE", not =
a node:
GOhA_elidible =3D expr:(GOhA_clause?) {return (expr =
=3D=3D "") ? ["COhE"] =C2=A0 : _node("COhE", =
expr);}

I could copy the whole=C2=A0bridi_ta=
il_t1 with all (!) dependent strings like=C2=A0bridi_tail_t2 etc. only in o=
rder to inject a COhE_elidible instead of "selbri" in=C2=A0bridi_=
tail_3. However, we should be fighting copy pasting, shouldn't we?

I don't have a full=
 grasp of how the javascript works, but isn't it always possible, for a=
ny elidable rule, to make the elision "visible" in the output by =
replacing "rule?" with "rule / rule_elided" and making =
"rule_elided" absorb nothing and return whatever you want it to r=
eturn?

I'd also like to show ZOhE=
 in x1 of {i broda mi} since we assume that if a selbri has x2 it must have=
 x1. Again the same question applies: how to restore it without copying the=
 whole "terms" part of the grammar?

This is not so clear to me. How would PEG know t=
hat x2 is filled? Having non-empty tail-terms is no guarantee that x2 gets =
filled.=C2=A0

mu'o mi'e xorxes
<=
br>





-- 

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.


--f46d04447e9f1b333405125cc93a--