Received: from mail-lb0-f184.google.com ([209.85.217.184]:34794) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1Yd4iy-0008EQ-Jg; Tue, 31 Mar 2015 15:33:36 -0700 Received: by lbiv13 with SMTP id v13sf11547708lbi.1; Tue, 31 Mar 2015 15:33:25 -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=02XGSy7BcyDoxIa+c58/ZIfdTGTErG5Hce805eScEzE=; b=XKwVOM5nlxo42+weNFDESIOcv4XyycOogYH0aCB+9dsWBwkp9Q7MMQfyZgk4nk8t6k ETXVJDeB9xGlX/A/taBv3vX18KmgUFEQ+FAijWNL3rLXiwOqwCT9Fgrhce9w0KujZrxK cE4ugUlkGx3MX1naxrCtu2zKA2IXoUYcZz75rkyMgBIn6aUGsXIferZaoyhDv30QC4oU n4pr38ckioCrGyaru+rr/ODqH5NgDycgbaM+3yspIOnLATMLNcGKgx78ZzjA2G5hqkFt 2kpx685rk+dX11DO+bwpuxLAQgWduaKMBkHUh2I8l0NqHvCKlC5fyUWNEbRtDJhMNeoq /ISQ== X-Received: by 10.152.206.12 with SMTP id lk12mr142238lac.21.1427841205534; Tue, 31 Mar 2015 15:33:25 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.152.205.4 with SMTP id lc4ls695890lac.104.gmail; Tue, 31 Mar 2015 15:33:25 -0700 (PDT) X-Received: by 10.112.125.67 with SMTP id mo3mr8680479lbb.6.1427841205051; Tue, 31 Mar 2015 15:33:25 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com. [2a00:1450:400c:c05::235]) by gmr-mx.google.com with ESMTPS id o3si907352wib.2.2015.03.31.15.33.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 15:33:25 -0700 (PDT) Received-SPF: pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:400c:c05::235 as permitted sender) client-ip=2a00:1450:400c:c05::235; Received: by mail-wi0-x235.google.com with SMTP id gn9so43749037wib.1 for ; Tue, 31 Mar 2015 15:33:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr78886324wjs.117.1427841204918; Tue, 31 Mar 2015 15:33:24 -0700 (PDT) Received: by 10.27.56.72 with HTTP; Tue, 31 Mar 2015 15:33:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Mar 2015 19:33:24 -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=047d7b86da3ad0a1a705129d2f21 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:c05::235 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.7 (-) X-Spam_score: -1.7 X-Spam_score_int: -16 X-Spam_bar: - Content-Length: 24175 --047d7b86da3ad0a1a705129d2f21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 31, 2015 at 6:54 AM, Gleki Arxokuna wrote: > > 2015-03-28 20:43 GMT+03:00 Jorge Llamb=C3=ADas : >> >> On Sat, Mar 28, 2015 at 4:05 AM, Gleki Arxokuna < >> gleki.is.my.name@gmail.com> wrote: >>> >>> >>>> 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 a= s >>> {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"? >> > It doesn't matter. This phrase (without {kei}) officially (in yacc) parse= s > as > (fasnu { KEI} {poi KU'O}) K= U > ]> VAU}) > Right, I thought that's what you meant. But you would need an explicit "kei" there if your new sumti rule is in effect. It would no longer be elidable in this case. > Maybe you meant it should be restored to "fasnu fa lo nu ta prenu _ku_ po= i > do sisku ke'a"? This is another option indeed. > I didn't mean it should be restored to anything. I said making "relative_clauses" a sumti could be weird, and that restoring "ta prenu poi do sisku" to "fasnu fa lo nu ta prenu poi do sisku" would be no restoration at all because you still have "ta prenu poi do sisku" in there. If you make "poi do sisku" a sumti, then "fasnu fa lo nu ta prenu poi do sisku" would no longer parse in the way it parses now, it would parse as (fasnu {} KU'O) VAU]> KEI} KU]> VAU}). In order to get the current parse, either "kei" or "vau" would no longer be elidable= . Although, I'm bad at distinguishing inner and outer relative clauses so > maybe I'd prefer {fasnu fa lonu ta prenu ku poi do sisku ke'a}. > Either way, I take it then that the sumti "poi do sisku" would not occupy a numbered place, but it would rather act like a tag or tagged sumti. But that doesn't correspond well with your proposed use of "FA relative-clause". I started this discussion not to issue any decrees but because few people > seem to be working on PEG when it's obvious that it can and should be > improved. > I understand. I'm just pointing out my issues with making "relative_clause" a sumti. > 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 k= u'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 don't insist on restoring {noi melbi} into {zo'e noi melbi}, but I woul= d > never guess that it is {zi'e} that is omitted here. > If no one including me (oh well, only two people here) like {broda noi > melbi} as {broda zo'e noi mo} then let's think this option is rejected. > Now I'm getting confused again, because you seem to be saying that "noi melbi"=3D"zo'e noi melbi" does occupy a numbered place. But this is contrar= y to what you were saying in the previous example. However, I would like it to be restored to {lo broda noi melbi}. If people > make mistakes it's because how they learnt or assumed something incorrect= ly > from existing books. > What is "it"? What would be restored to "lo broda noi melbi"? Not "broda noi melbi", I suppose. An English phrase "Does which is beautiful" is {[fasnu fa lo nu] zukte noi > melbi} or {[fasnu fa lo nu] zukte ku noi melbi}. > I don't understand what you meant there. If relying on English (and some other European languages) doesn't matter > here at all then I can see only one possible explanation of this common > mistake: people have been learning gismu from their glosswords incorrectl= y > assuming that gismu may mean nouns whereas they never mean nouns but > predicates or (very roughly) verbs. {i mlatu} never means "a cat" but "It > is a cat". > Partly true, but notice that even if you do understand that "mlatu" means "is-a-cat", you could still think that "ta mlatu poi mi nelci" was "that is-a-cat that-I-like", where "that-I-like" works like a tanru modifier on "is-a-cat", much like you could say "ta mlatu co blabi", "that is-a-cat of-type-is-white". 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-clause= s? >> >> Are you able to test this suggestion? I tried, it didn't work for me. > I probably should be able to test it with the site I mentioned earlier, with some work. I'm not sure that it's a high priority for me at this point. Which case did it fail with? > 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". >> >> I can see now that what I proposed wouldn't work for "ro poi broda gi'e brode cu brodi" (but maybe yes for "ro lo poi ...". I'm not sure I see why it wouldn't work for "lo ci cu broda". Maybe adding this modification: sumti-5 <- quantifier? sumti-6 relative-clauses? / quantifier selbri? KU-clause? free* relative-clauses? would help with the "ro poi" case. But I'm just throwing ideas here, not making any serious proposal at this point. > la xalbo suggested having a list of test sentences so that we can quickly > test whether some change affects any reference test sentences (it shouldn= 't > affect to preserve or even increase backward compatibility). > Yes, clearly any changes need to be thoroughly tested before being approved. Making tanru-unit elidable would make most of this sumti-tail issue moot though, since in that case the selbri in sumti-tail and anywhere else would automatically be elidable as well. One problem I can see with that would be the dangling "co", "cei", "bo" and tanru connectives that would then be allowed. 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. --047d7b86da3ad0a1a705129d2f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Mar 31, 2015 at 6:54 AM, Gleki Arxokuna <gleki.is.my.name= @gmail.com> wrote:
2015-03-28 20= :43 GMT+03:00 Jorge Llamb=C3=ADas <jjllambias@gmail.com>:=
On Sat, Mar 28, 2015 at 4:05 AM, Gleki Arxokuna <gleki.is.my.name@gmail.com> wrote:
=

<= div class=3D"gmail_quote">
sumti_4 =3D expr:(sumti_5 / relative= _clauses / gek sumti gik sumti_4) {return _node("sumti_4", ex= pr);}

= This could be dangerous, as it makes "ta prenu poi do sisku" gram= matical, but not with the expected meaning.

I don't know what is the expected meani= ng here.

So= mething like "ta me lo prenu poi do sisku", a relatively frequent= error, I think.

It can be rest= ored to {ta prenu zo'e poi do sisku ke'a} or instead to something l= ike {fasnu fa lo nu ta prenu poi do sisku ke'a} or instead as {lo ta pr= enu poi do sisku ke'a cu co'e}.

Did you mean "fasnu fa lo nu ta prenu _kei= _ poi do sisku ke'a"?
<= div>It doesn't matter. This phrase (without {kei}) officially (in yacc)= parses as
(fasnu {<fa [lo ({nu <ta [prenu VAU]> KE= I} {poi <do [sisku VAU]> KU'O}) KU ]> VAU})
<= /div>

Right, I thought that's wha= t you meant. But you would need an explicit "kei" there if your n= ew sumti rule is in effect. It would no longer be elidable in this case.
=C2=A0
Maybe you meant it should be res= tored to "fasnu fa lo nu ta prenu _ku_ poi do sisku ke'a"? Th= is is another option indeed.

I didn't mean it should be restored to anything. I said= making "relative_clauses" a sumti could be weird, and that resto= ring "ta prenu poi do sisku" to "fasnu fa lo nu ta prenu poi= do sisku" would be no restoration at all because you still have "= ;ta prenu poi do sisku" in there. If you make "poi do sisku"= a sumti, then "fasnu fa lo nu ta prenu poi do sisku" would no lo= nger parse in the way it parses now, it would parse as (fasnu {<fa [lo (= {nu <ta [prenu (poi {do <sisku VAU>} KU'O) VAU]> KEI} KU]&g= t; VAU}). In order to get the current parse, either "kei" or &quo= t;vau" would no longer be elidable.

<= div>Although, I'm bad at distinguishing inner and outer relative clause= s so maybe I'd prefer {fasnu fa lonu ta prenu ku poi do sisku ke'a}= .

Either way, I tak= e it then that the sumti "poi do sisku" would not occupy a number= ed place, but it would rather act like a tag or tagged sumti. But that does= n't correspond well with your proposed use of "FA relative-clause&= quot;.=C2=A0

I started this discussio= n not to issue any decrees but because few people seem to be working on PEG= when it's obvious that it can and should be improved.

I understand. I'm just pointing= out my issues with making "relative_clause" a sumti.=C2=A0
=
=C2=A0
Also things lika {da poi prenu ku'o noi me= lbi".

H= ow 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 n= oi 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 si= ngle sumti with two relative clauses.=C2=A0

I don't insist on restoring {noi melbi}= into {zo'e noi melbi}, but I would never guess that it is {zi'e} t= hat is omitted here.
If no one including me (oh well, only two pe= ople here) like {broda noi melbi} as {broda zo'e noi mo} then let's= think this option is rejected.
Now I'm getting confused again, because you seem to be say= ing that "noi melbi"=3D"zo'e noi melbi" does occupy= a numbered place. But this is contrary to what you were saying in the prev= ious example.=C2=A0

<= div class=3D"gmail_extra">
However, I would = like it to be restored to {lo broda noi melbi}. If people make mistakes it&= #39;s because how they learnt or assumed something incorrectly from existin= g books.

What is &q= uot;it"? What would be restored to "lo broda noi melbi"? Not= "broda noi melbi", I suppose.=C2=A0

An English phrase "Does which is beautiful" is {[fasnu = fa lo nu] zukte noi melbi} or=C2=A0{[fasnu fa lo nu] zukte ku noi melbi}.

I don't understa= nd what you meant there.=C2=A0

If rel= ying on English (and some other European languages) doesn't matter here= at all then I can see only one possible explanation of this common mistake= : people have been learning gismu from their glosswords incorrectly assumin= g that gismu may mean nouns whereas they never mean nouns but predicates or= (very roughly) verbs. {i mlatu} never means "a cat" but "It= is a cat".

Pa= rtly true, but notice that even if you do understand that "mlatu"= means "is-a-cat", you could still think that "ta mlatu poi = mi nelci" was "that is-a-cat that-I-like", where "that-= I-like" works like a tanru modifier on "is-a-cat", much like= you could say "ta mlatu co blabi", "that is-a-cat of-type-i= s-white".=C2=A0


=
<= div class=3D"gmail_quote">
As for you suggestion it&= #39;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 p= eg, btw?)

Ma= ybe=C2=A0something like:
  sumti-tail-1 <-=C2=A0quantifier sumti / quantifier? selbri? relative-clauses?
<=
/pre>
Are you able to test this s= uggestion? I tried, it didn't work for me.

I probably should be able to test it with the s= ite I mentioned earlier, with some work. I'm not sure that it's a h= igh priority for me at this point.=C2=A0 Which case did it fail with?=C2=A0= 
I=
 haven't thought out all the ramifications, but this should allow thing=
s like "ro poi broda gi'e brode cu brodi" and "lo ci cu =
broda".
=
I can see now that what I proposed wouldn'= ;t work for "ro poi broda gi'e brode cu brodi" (but maybe yes= for "ro lo poi ...". I'm not sure I see why it wouldn't = work for "lo ci cu broda".=C2=A0

Maybe a= dding this modification:
  sumti-5 <- quantifier? sumti-6 relative-clauses? / quantifier selbr=
i? KU-clause? free* relative-clauses?
would help with the "ro poi" case. But I'm j= ust throwing ideas here, not making any serious proposal at this point.
=C2=A0
la xalbo suggested having a list of te= st sentences so that we can quickly test whether some change affects any re= ference test sentences (it shouldn't affect to preserve or even increas= e backward compatibility).

Yes, clearly any changes need to be thoroughly tested before being = approved. Making tanru-unit elidable would make most of this sumti-tail iss= ue moot though, since in that case the selbri in sumti-tail and anywhere el= se would automatically be elidable as well. One problem I can see with that= would be the dangling "co", "cei", "bo" and = tanru connectives that would then be allowed.

mu&#= 39;o mi'e xorxes

--
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.
--047d7b86da3ad0a1a705129d2f21--