Received: from mail-wg0-f59.google.com ([74.125.82.59]:33239) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1Ycssg-0008GL-W5; Tue, 31 Mar 2015 02:54:51 -0700 Received: by wggz12 with SMTP id z12sf2800947wgg.0; Tue, 31 Mar 2015 02:54:40 -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=QCjVLSoTCSI06ZYh4AIJPLFwL8b12EPVKHqRIGxDEB0=; b=IJ9osk8U45bq7uxy8DGG9orQeSkD+P5+TqNtVKiQ2jus/Dj3wfQ6AbU91sXaPD6q7K zx4WNAfSaKjgIxxytlzSXpLp+NMW4yGmlxvwpDOyU7dhExgqIlBrZcakfctb7MaQPMiO 9Yy36j3lwg17YLG5uycqgpalFcakFnsIjckKzCVYHx7Y4q0B5MG4RqluemCkLAZgZow6 GCmD/eMs3N3Azs9mdn0PvPWs0lVP0xVLjlsnK9ZsKtQ5AfZEaeEzoKa3YSqerHrh2ESl Ng5CmQabgUIWM+yUYmhRjWrzSUX8FR34mqxFe+Wdp0VhgatiOkcvz/KP9cvSJyniK231 fNFA== X-Received: by 10.180.100.67 with SMTP id ew3mr11642wib.5.1427795680072; Tue, 31 Mar 2015 02:54:40 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.180.84.134 with SMTP id z6ls845590wiy.21.gmail; Tue, 31 Mar 2015 02:54:38 -0700 (PDT) X-Received: by 10.180.97.200 with SMTP id ec8mr492655wib.5.1427795678409; Tue, 31 Mar 2015 02:54:38 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com. [2a00:1450:400c:c05::22b]) by gmr-mx.google.com with ESMTPS id a14si482716wib.3.2015.03.31.02.54.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 02:54:38 -0700 (PDT) Received-SPF: pass (google.com: domain of gleki.is.my.name@gmail.com designates 2a00:1450:400c:c05::22b as permitted sender) client-ip=2a00:1450:400c:c05::22b; Received: by mail-wi0-x22b.google.com with SMTP id o5so6922342wix.1 for ; Tue, 31 Mar 2015 02:54:38 -0700 (PDT) X-Received: by 10.194.240.73 with SMTP id vy9mr73958503wjc.41.1427795677326; Tue, 31 Mar 2015 02:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.240.197 with HTTP; Tue, 31 Mar 2015 02:54:17 -0700 (PDT) In-Reply-To: References: From: Gleki Arxokuna Date: Tue, 31 Mar 2015 12:54:17 +0300 Message-ID: Subject: Re: [bpfk] Improvements to fragments in ilmentufa parser To: bpfk-list@googlegroups.com Content-Type: multipart/alternative; boundary=001a11c28c8e28b19005129296cb 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::22b 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: - --001a11c28c8e28b19005129296cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: >> >> 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, tha= t > 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. > And that's what I'd like to have. That's why I'm against fragments in PEG itself. {mi penmi lo pendo - be ma} - this {be ma} fragment isn't able to restore the full tree. > > >> 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"? > It doesn't matter. This phrase (without {kei}) officially (in yacc) parses as (fasnu { KEI} {poi KU'O}) KU ]> VAU}) Maybe you meant it should be restored to "fasnu fa lo nu ta prenu _ku_ poi do sisku ke'a"? This is another option indeed. > 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 t= he > 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? > I don't provide answers here. I ask myself how we should deal with it and should we deal with it at all. My personal preference is that it's {fasnu fa lonu ta prenu poi do sisku ke'a} whatever that means. 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}. 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. > >> Also things lika {da poi prenu ku'o noi melbi". >>> >> >> How is this supposed to parse according to you? I can see it again eithe= r >> 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 don't insist on restoring {noi melbi} into {zo'e noi melbi}, but I would 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. 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 incorrectly from existing books. An English phrase "Does which is beautiful" is {[fasnu fa lo nu] zukte noi melbi} or {[fasnu fa lo nu] zukte ku noi melbi}. 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 incorrectly 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". > > 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. > ca'e di'u assumed as an axiom until someone else raises their head. 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= ? > > Are you able to test this suggestion? I tried, it didn't work for me. > 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". > > 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). --=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. --001a11c28c8e28b19005129296cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-03-28 20:43 GMT+03:00 Jorge Llamb=C3=ADas <jjllambias@gmail.co= m>:

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>:
<= span>

I missed the part where "noi mo cu co&= #39;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-parser interpretation strategy, that has to decide whether a given stri= ng 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 c= an handle that pre-parsing stage. (b) seems to be about what to feed the pa= rser as input rather than about what the parser should output given some in= put.

And that's= what I'd like to have. That's why I'm against fragments in PEG= itself. {mi penmi lo pendo - be ma} - this {be ma} fragment isn't able= to restore the full tree.
=C2=A0
= =C2=A0
su= mti_4 =3D expr:(sumti_5 / relative_clauses / gek sumti gik sumti_4) = {return _node("sumti_4", expr);}

This could be dangerous, as it makes &= quot;ta prenu poi do sisku" grammatical, but not with the expected mea= ning.

I don&= #39;t know what is the expected meaning here.

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

<= /div>
It can be restored to {ta prenu zo'e poi do sisk= u ke'a} or instead to something like {fasnu fa lo nu ta prenu poi do si= sku ke'a} or instead as {lo ta prenu poi do sisku ke'a cu co'e}= .

Did you me= an "fasnu fa lo nu ta prenu _kei_ poi do sisku ke'a"?
It doesn't matter. This phrase (witho= ut {kei}) officially (in yacc) parses as
(fasnu {<fa [lo = ({nu <ta [prenu VAU]> KEI} {poi <do [sisku VAU]> KU'O}) KU = ]> VAU})

Maybe you meant it should be restored = to "fasnu fa lo nu ta prenu _ku_ poi do sisku ke'a"? This is = another option indeed.

=C2=A0
Otherwise you just have the same original "pa prenu poi do s= isku" 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 &q= uot;prenu". Is the stand-alone relative clause to be taken as an ordin= ary 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?

I don't provide answers here. I ask myself how we should deal with i= t and should we deal with it at all.

My personal p= reference is that it's {fasnu fa lonu ta prenu poi do sisku ke'a} w= hatever that means. 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}.

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.

=C2=A0
Also = things lika {da poi prenu ku'o noi melbi".
=

How is this supposed to parse accor= ding 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 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

I don'= ;t insist on restoring {noi melbi} into {zo'e noi melbi}, but I would n= ever 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 {bro= da zo'e noi mo} then let's think this option is rejected.

However, I would like it to be restored to {lo broda noi me= lbi}. If people make mistakes it's because how they learnt or assumed s= omething incorrectly from existing books.

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

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 co= mmon mistake: people have been learning gismu from their glosswords incorre= ctly assuming that gismu may mean nouns whereas they never mean nouns but p= redicates or (very roughly) verbs. {i mlatu} never means "a cat" = but "It is a cat".
=C2=A0
=
I think it's safer to = require a "lo" for bare relative clauses: "lo noi pendo cu m= elbi" (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.
<= div>
ca'e di'u assumed as an axiom until someone else= raises their head.

<= div class=3D"gmail_extra">
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 noi pendo ja'a melbi cu co'e} so it requires separate commits (= do you have ideas where to patch the peg, btw?)

Maybe=C2=A0something = like:
<=
font face=3D"arial, helvetica, sans-serif">  sumti-tail-1 <-=C2=A0quantifier sumti / =
quantifier? s=
elbri? relative-clauses?
<= div>
Are you able to test this suggestion? I tried, it didn&#= 39;t work for me.
=C2=A0
<= div class=3D"gmail_extra">
I haven't thought out all the ramifications, but this should allow t=
hings like "ro poi broda gi'e brode cu brodi" and "lo ci=
 cu broda".

=
la xalbo suggested having a list of test sentences so that we ca= n quickly test whether some change affects any reference test sentences (it= shouldn't affect to preserve or even increase backward compatibility).=

--
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.
--001a11c28c8e28b19005129296cb--