Received: from mail-qa0-f59.google.com ([209.85.216.59]:46621) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1YLfdy-00020E-4N for lojban-list-archive@lojban.org; Wed, 11 Feb 2015 14:20:35 -0800 Received: by mail-qa0-f59.google.com with SMTP id k15sf1726070qaq.4 for ; Wed, 11 Feb 2015 14:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=/2e//g8dYRIlle1SknZ7wl4nVvoU63gimHchFDP8eXw=; b=QkJ6S56aUqMkWnPhwj/oTeoK4tAFFRkzaL0VxYRmV/89C1T5Ylj5EjATGI1wum+YlJ pAuBzstCOJYn2Lor/wR9a9ozDJwZVZK6sHu72EYfYRN3HdhRSvLpdBCWcHTgVchxORPy UUVLo1r6XS920qNyETs+4NzrDfXXNJx2665sFIHRcWPL4DbquFaJ4F/7XGo06NTjux+F 6lTnI9BeIbw2cu+qCcBADs3c6wuau41hckuhVEDkbrq9WiImOnI6wP+1TM1pOGMMirwb EMK7r6mdTNhiG29l2G0kS4zGBYOiBR9K75Ome8NrKtQYojj6WqFpIVWgHI0lDMZ0kLpD rJCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=/2e//g8dYRIlle1SknZ7wl4nVvoU63gimHchFDP8eXw=; b=NQTPjo2w/vOTLUwO/tq0aMN4qb46ULpKTnjFjf5ZfheIWEDf+FVWUBejXdIpPBSBCf rZYqaiAiVyxbLFHnemAp3bTIlhHkRLc/WUhkvI3zNv3TVYodUZIN0SrWAVHH4RDCEjkh KrRxEBiCgm4YPzCfuv7mPe9ENHUhqL873xdu7k4VLA62qUBQ75rQ40ViJmzKa8TjOvgr t5kjQa4MCr4Jb16yEJo6WyXqortg6OB4G9aSIDuUCHT21scWCBsEXQpzbN8OQ01XFyHp P2c49Ip3kW+nbYGbKnYL0ZhLCiTbYYs8dAJ2p3ttGgoXr016bGLzIB0zn1YsRdl6SglB lnwA== X-Received: by 10.140.94.74 with SMTP id f68mr18306qge.13.1423693219933; Wed, 11 Feb 2015 14:20:19 -0800 (PST) X-BeenThere: lojban@googlegroups.com Received: by 10.140.34.131 with SMTP id l3ls497114qgl.5.gmail; Wed, 11 Feb 2015 14:20:19 -0800 (PST) X-Received: by 10.140.83.41 with SMTP id i38mr17639qgd.11.1423693219643; Wed, 11 Feb 2015 14:20:19 -0800 (PST) Date: Wed, 11 Feb 2015 14:20:19 -0800 (PST) From: ianek To: lojban@googlegroups.com Message-Id: <50d5006f-f02b-4a28-9894-6608729585fc@googlegroups.com> In-Reply-To: References: <20150204124517.GA1243@kuebelreiter.informatik.Uni-Osnabrueck.DE> Subject: Re: [lojban] the myth of monoparsing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1017_1908240328.1423693219230" X-Original-Sender: janek37@gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 0.7 (/) X-Spam_score: 0.7 X-Spam_score_int: 7 X-Spam_bar: / X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: On Wednesday, February 11, 2015 at 1:50:49 PM UTC+1, la gleki wrote: > > > > 2015-02-09 23:22 GMT+03:00 ianek >: > >> >> >> On Monday, February 9, 2015 at 11:54:41 AM UTC+1, la gleki wrote: >>> >>> >>> >>> 2015-02-08 4:34 GMT+03:00 ianek : >>> >>>> >>>> >>>> On Friday, February 6, 2015 at 8:13:30 AM UTC+1, la gleki wrote: >>>>> >>>>> >>>>> >>>>> 2015-02-04 15:45 GMT+03:00 v4hn : >>>>> >>>>>> On Tue, Feb 03, 2015 at 11:42:32AM +0300, Gleki Arxokuna wrote: >>>>>> > "Fred saw a plane flying over Zurich" can have several meanings >>>>>> >>>>>> Yes. >>>>>> However, for me, the issue here is that we (hopefully..) agree >>>>>> that there are different parse trees (which yield the different >>>>>> meanings). >>>>>> >>>>> >>>>> No, several trees arise after you interpret the sentence. >>>>> >>>> >>>> But if you had an English parser, it would yield several trees without >>>> any interpreting. >>>> >>> >>> Sure! Because English parsers lack the ability to find something common >>> in all of the parse trees. >>> >> >> No. It's because words in an English sentence can be parsed as different >> syntactic structures. That's what parsing means: determining structures >> formed by words. Not "finding something common". >> > > You yourself just showed several parses of the same sentence. > This is how usual English parsers are constructed. > > However, there is another option to monoparse this English sentence. > > You mix English language and one current theory of how to parse it. > > >> >>> >>> >>>> Like this: >>>> >>>> "Fred saw a plane flying over Zurich" >>>> NAME VERB-PAST ARTICLE COUNTABLE-NOUN VERB-ING PREPOSITION NAME >>>> >>>> Some (much simplified) rules could be: >>>> >>>> Sentence ::= Noun-Phrase Verb Noun-Phrase >>>> Sentence ::= Noun-Phrase Verb Noun-Phrase Adverbial-Phrase >>>> Noun-Phrase ::= NAME | ARTICLE COUNTABLE-NOUN | Noun-Phrase VERB-ING >>>> Prepositional-Clause >>>> Verb ::= VERB-PAST >>>> Adverbial-Phrase ::= VERB-ING Preposition-Clause >>>> [...] Content analysis details: (0.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: googlegroups.com] 2.7 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org [listed in googlegroups.com.rhsbl.ahbl.org. IN] [A] 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (janek37[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different ------=_Part_1017_1908240328.1423693219230 Content-Type: multipart/alternative; boundary="----=_Part_1018_1274408398.1423693219230" ------=_Part_1018_1274408398.1423693219230 Content-Type: text/plain; charset=UTF-8 On Wednesday, February 11, 2015 at 1:50:49 PM UTC+1, la gleki wrote: > > > > 2015-02-09 23:22 GMT+03:00 ianek >: > >> >> >> On Monday, February 9, 2015 at 11:54:41 AM UTC+1, la gleki wrote: >>> >>> >>> >>> 2015-02-08 4:34 GMT+03:00 ianek : >>> >>>> >>>> >>>> On Friday, February 6, 2015 at 8:13:30 AM UTC+1, la gleki wrote: >>>>> >>>>> >>>>> >>>>> 2015-02-04 15:45 GMT+03:00 v4hn : >>>>> >>>>>> On Tue, Feb 03, 2015 at 11:42:32AM +0300, Gleki Arxokuna wrote: >>>>>> > "Fred saw a plane flying over Zurich" can have several meanings >>>>>> >>>>>> Yes. >>>>>> However, for me, the issue here is that we (hopefully..) agree >>>>>> that there are different parse trees (which yield the different >>>>>> meanings). >>>>>> >>>>> >>>>> No, several trees arise after you interpret the sentence. >>>>> >>>> >>>> But if you had an English parser, it would yield several trees without >>>> any interpreting. >>>> >>> >>> Sure! Because English parsers lack the ability to find something common >>> in all of the parse trees. >>> >> >> No. It's because words in an English sentence can be parsed as different >> syntactic structures. That's what parsing means: determining structures >> formed by words. Not "finding something common". >> > > You yourself just showed several parses of the same sentence. > This is how usual English parsers are constructed. > > However, there is another option to monoparse this English sentence. > > You mix English language and one current theory of how to parse it. > > >> >>> >>> >>>> Like this: >>>> >>>> "Fred saw a plane flying over Zurich" >>>> NAME VERB-PAST ARTICLE COUNTABLE-NOUN VERB-ING PREPOSITION NAME >>>> >>>> Some (much simplified) rules could be: >>>> >>>> Sentence ::= Noun-Phrase Verb Noun-Phrase >>>> Sentence ::= Noun-Phrase Verb Noun-Phrase Adverbial-Phrase >>>> Noun-Phrase ::= NAME | ARTICLE COUNTABLE-NOUN | Noun-Phrase VERB-ING >>>> Prepositional-Clause >>>> Verb ::= VERB-PAST >>>> Adverbial-Phrase ::= VERB-ING Preposition-Clause >>>> Preposition-Clause ::= PREPOSITION Noun-Phrase >>>> >>>> This simple grammar yields two parse trees for that sentence: >>>> >>>> Sentence >>>> ----Noun-Phrase >>>> --------NAME >>>> ------------Fred >>>> ----Verb >>>> --------VERB-PAST >>>> ------------saw >>>> ----Noun-Phrase >>>> --------Noun-Phrase >>>> ------------ARTICLE >>>> ----------------a >>>> ------------NOUN >>>> ----------------plane >>>> --------VERB-ING >>>> ------------flying >>>> --------Prepositional-Clause >>>> ------------PROPOSITION >>>> ----------------over >>>> ------------Noun-Phrase >>>> ----------------NAME >>>> --------------------Zurich >>>> >>>> Sentence >>>> ----Noun-Phrase >>>> --------NAME >>>> ------------Fred >>>> ----Verb >>>> --------VERB-PAST >>>> ------------saw >>>> ----Noun-Phrase >>>> --------Noun-Phrase >>>> ------------ARTICLE >>>> ----------------a >>>> ------------NOUN >>>> ----------------plane >>>> ----Adverbial-Phrase >>>> --------VERB-ING >>>> ------------flying >>>> --------Prepositional-Clause >>>> ------------PROPOSITION >>>> ----------------over >>>> ------------Noun-Phrase >>>> ----------------NAME >>>> --------------------Zurich >>>> >>>> Formal grammars for natural languages do exist, although they're not >>>> perfect, but the problem with multiple grammatically sensible parses (often >>>> millions of trees and more) is much greater than the problem with >>>> nonsensible trees or correct sentences that don't parse at all. >>>> >>>> Lojban was carefully designed to avoid this problem. And it doesn't >>>> have anything to do with {xi PA}. The Lojban grammar specifies XI clauses >>>> unambiguously. Parse trees are unique. Monoparsing is not a myth. XI >>>> clauses may add semantic ambiguity on a different level then, say, simple >>>> {zo'e}, but it doesn't have anything to do with syntactic ambiguity. >>>> >>> >>> It specifies to which head a clause should attach. And since it's {mo'e >>> zo'e} it's vague to which head it attaches. If the parser you use doesn't >>> allow for that the only thing that can be done is to provide several >>> possible trees. >>> >> >> It's a feature of a language, not a parser. If English had a pronoun, >> say, 'lar', which would mean 'the subject or the object of the main >> sentence', you could say "Fred saw a plane as lar flew over Zurich", which >> would be ambiguous semantically, but not syntactically. >> > > Even in current English theory there are a lot of zero morphemes. What I'm > proposing is just another zero morpheme. > > > This is what And agreed with me. > > >> >>> >>>> >>> {la fred pu viska lo vinji do'e lo se xi vei mo'e zo'e nei poi vofli >>>> ga'u la tsurix} has only one syntax tree, regardless of the number of >>>> possible semantic interpretations. >>>> >>> >>> If you applied {mo'e zo'e} to the English sentence you will still get >>> the only syntax tree. >>> >> >> You can't "apply" {mo'e zo'e} to the English sentence, because it's not >> there. Likewise you don't "apply" {mo'e zo'e} to the Lojban sentence. You >> just parse it, because it's there. >> In English you can have phrases like 'X of Y of Z' which could be parsed >> as '(X of Y) of Z' or 'X of (Y of Z)'. In Lojban it's not possible, but you >> can say ''either (X of Y) of Z or X of (Y of Z)", which is not >> syntactically ambiguous. You can't apply "either... or" to the English >> sentence, because you can't parse words which aren't there. >> > > As I just said English parsers use this "add words that aren't there" all > the time. > I was searching, but I haven't found any English parser (but I know a Polish one). What parsers do you refer to? > > >> >>> >>>> In English you can have sentences that are semantically ambiguous due >>>> to syntactic ambiguity. In Lojban you can have sentences with (roughly) the >>>> same semantic ambiguity as the English ones, but syntactically unambiguous. >>>> >>>> >>>>> >>>>>> > {la fred pu viska lo vinji do'e lo se xi vei mo'e zo'e nei poi >>>>>> vofli ga'u >>>>>> > la tsurix} >>>>>> >>>>>> camxes only produces one parse tree for that. >>>>>> >>>>> >>>>> And for English you don't provide any parses at all. >>>>> May be someone should just parse the original English sentence as >>>>> camxes does for Lojban one? >>>>> I won't be surprised if such parser for English doesn't exist since >>>>> those who write them might mix parsing and interpretation of it. The latter >>>>> would be replacing {mo'e zo'e} with some PA which will immediately lead to >>>>> several syntactic trees. >>>>> >>>>> So I both disagree and agree with you on whether English sentence has >>>>> several syntactic trees. If using one term for two operations is stopped >>>>> the contradiction disappears. >>>>> >>>>> >>>>> >>>>>> If you think it should produce more then one, raise a bug report. >>>>>> >>>>> >>>>> I'm not aware of any Lojban parsers that perform interpretation >>>>> operation. In most cases you just need context and one interpretation. But >>>>> this is semantic analysis. Producing all possible syntactic trees is a task >>>>> needed more seldom. >>>>> >>>> >>>> Camxes is intended to produce all possible syntactic trees, and there's >>>> only one of them for any valid sentence. >>>> >>> >>> You may invent a Lojban parser that won't be able to parse {mo'e zo'e}. >>> Then you will need workarounds to output several trees. >>> >> >> XI clauses have an ambiguous syntax, so I don't see how I'd need >> workarounfds and several trees. Of course, I could invent a Lojban parser >> that won't be able to parse anything, but what's the point? {mo'e zo'e} >> from the parser's view is just MOhE KOhA. If I can't parse it, then I have >> an incomplete parser. >> > > And this is what I state for English: its current parsers are incomplete > and further improvements will make polyparsed sentences monoparsed. > > >> >> What you mean sounds rather like a semantic analyzer, which is extremely >> hard for any language, including Lojban. >> >> mu'o mi'e ianek >> >> >>> >>> >>>> >>>> mu'o mi'e ianek >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "lojban" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to lojban+un...@googlegroups.com. >>>> To post to this group, send email to loj...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/lojban. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "lojban" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to lojban+un...@googlegroups.com . >> To post to this group, send email to loj...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/lojban. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "lojban" group. To unsubscribe from this group and stop receiving emails from it, send an email to lojban+unsubscribe@googlegroups.com. To post to this group, send email to lojban@googlegroups.com. Visit this group at http://groups.google.com/group/lojban. For more options, visit https://groups.google.com/d/optout. ------=_Part_1018_1274408398.1423693219230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, February 11, 2015 at 1:50:49 PM UTC+= 1, la gleki wrote:


2015-02-09 23:22 GMT+03:00 ian= ek <jan...@gmail.com>:


On Monday, February 9, 2015 at 11:54:41 AM UTC+1, la g= leki wrote:
<= br>

2015-02-08 4:34 GMT+03:00 ianek <jan...@gmail.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


On Friday, February = 6, 2015 at 8:13:30 AM UTC+1, la gleki wrote:


201= 5-02-04 15:45 GMT+03:00 v4hn <m...= @v4hn.de>:
On Tue, Feb 03, 2015 at = 11:42:32AM +0300, Gleki Arxokuna wrote:
> "Fred saw a plane flying over Zurich" can have several meanings

Yes.
However, for me, the issue here is that we (hopefully..) agree
that there are different parse trees (which yield the different meanings).<= br>

No, several trees arise after you inter= pret the sentence.

But = if you had an English parser, it would yield several trees without any inte= rpreting.

Sure! Because English= parsers lack the ability to find something common in all of the parse tree= s.

No. It's because wor= ds in an English sentence can be parsed as different syntactic structures. = That's what parsing means: determining structures formed by words. Not "fin= ding something common".

You= yourself just showed several parses of the same sentence.
This i= s how usual English parsers are constructed. 

However, there is another option to monoparse this English sentence.=

You mix English language and one current theory of how = to parse it.

 
 
Like this:

"Fr= ed saw a plane flying over Zurich"
NAME VERB-PAST ARTICLE COUNTAB= LE-NOUN VERB-ING PREPOSITION NAME

Some (much simplified) rules could= be:

Sentence ::=3D Noun-Phrase Verb Noun-Phrase
Sentence ::=3D N= oun-Phrase Verb Noun-Phrase Adverbial-Phrase
Noun-Phrase ::=3D NAME | AR= TICLE COUNTABLE-NOUN | Noun-Phrase VERB-ING Prepositional-Clause
Verb ::= =3D VERB-PAST
Adverbial-Phrase ::=3D VERB-ING Preposition-Clause
Prep= osition-Clause ::=3D PREPOSITION Noun-Phrase

This simple grammar yie= lds two parse trees for that sentence:

Sentence
----Noun-Phrase--------NAME
------------Fred
----Verb
--------VERB-PAST
----= --------saw
----Noun-Phrase
--------Noun-Phrase
------------ARTICL= E
----------------a
------------NOUN
----------------plane
----= ----VERB-ING
------------flying
--------Prepositional-Clause
-----= -------PROPOSITION
----------------over
------------Noun-Phrase
--= --------------NAME
--------------------Zurich

Sentence
----Nou= n-Phrase
--------NAME
------------Fred
----Verb
--------VERB-PA= ST
------------saw
----Noun-Phrase
--------Noun-Phrase
--------= ----ARTICLE
----------------a
------------NOUN
----------------pla= ne
----Adverbial-Phrase
--------VERB-ING
------------flying
---= -----Prepositional-Clause
------------PROPOSITION
----------------ove= r
------------Noun-Phrase
----------------NAME
-------------------= -Zurich

Formal grammars for natural languages do exist, although the= y're not perfect, but the problem with multiple grammatically sensible pars= es (often millions of trees and more) is much greater than the problem with= nonsensible trees or correct sentences that don't parse at all.

Loj= ban was carefully designed to avoid this problem. And it doesn't have anyth= ing to do with {xi PA}. The Lojban grammar specifies XI clauses unambiguous= ly. Parse trees are unique. Monoparsing is not a myth. XI clauses may add s= emantic ambiguity on a different level then, say, simple {zo'e}, but it doe= sn't have anything to do with syntactic ambiguity.

It specifies to which head a clause should attach= . And since it's {mo'e zo'e} it's vague to which head it attaches. If the p= arser you use doesn't allow for that the only thing that can be done is to = provide several possible trees.

It's a feature of a language, not a parser. If English ha= d a pronoun, say, 'lar', which would mean 'the subject or the object of the= main sentence', you could say "Fred saw a plane as lar flew over Zurich", = which would be ambiguous semantically, but not syntactically.

Even in current English theory there are= a lot of zero morphemes. What I'm proposing is just another zero morpheme.=
 

This is what And agreed with me.



 
{la fred pu viska lo vinji do'e lo se xi v= ei mo'e zo'e nei poi vofli ga'u la tsurix} has only one syntax tree, regard= less of the number of possible semantic interpretations.

If you applied {mo'e zo'e} to the Engli= sh sentence you will still get the only syntax tree.
<= /div>

You can't "apply" {mo'e zo'e} to the Engl= ish sentence, because it's not there. Likewise you don't "apply" {mo'e zo'e= } to the Lojban sentence. You just parse it, because it's there.
In Engl= ish you can have phrases like 'X of Y of Z' which could be parsed as '(X of= Y) of Z' or 'X of (Y of Z)'. In Lojban it's not possible, but you can say = ''either (X of Y) of Z or X of (Y of Z)", which is not syntactically ambigu= ous. You can't apply "either... or" to the English sentence, because you ca= n't parse words which aren't there.

As I just said English parsers use this "add words that aren't the= re"  all the time.

I was = searching, but I haven't found any English parser (but I know a Polish one)= . What parsers do you refer to?
 

=

=


In English you can have sentences that are semantically amb= iguous due to syntactic ambiguity. In Lojban you can have sentences with (r= oughly) the same semantic ambiguity as the English ones, but syntactically = unambiguous.
 

> {la fred pu viska lo vinji do'e lo se xi vei mo'e zo'e nei poi vofli g= a'u
> la tsurix}

camxes only produces one parse tree for that.
<= br>
And for English you don't provide any parses at all.
May be someone should just parse the original English sentence as camxes = does for Lojban one?
I won't be surprised if such parser for Engl= ish doesn't exist since those who write them might mix parsing and interpre= tation of it. The latter would be replacing {mo'e zo'e} with some PA which = will immediately lead to several syntactic trees.

= So I both disagree and agree with you on whether English sentence has sever= al syntactic trees. If using one term for two operations is stopped the con= tradiction disappears.

 
If you think it should produce more then one, raise a bug report.

I'm not aware of any Lojban parsers that perform= interpretation operation. In most cases you just need context and one inte= rpretation. But this is semantic analysis. Producing all possible syntactic= trees is a task needed more seldom.

Camxes is intended to produce all possible syntactic trees, a= nd there's only one of them for any valid sentence.

You may invent a Lojban parser that won't be able = to parse {mo'e zo'e}. Then you will need workarounds to output several tree= s.

XI clauses have an a= mbiguous syntax, so I don't see how I'd need workarounfds and several trees= . Of course, I could invent a Lojban parser that won't be able to parse any= thing, but what's the point? {mo'e zo'e} from the parser's view is just MOh= E KOhA. If I can't parse it, then I have an incomplete parser.

And this is what I state for English: i= ts current parsers are incomplete and further improvements will make polypa= rsed sentences monoparsed.
 

What you mean sounds rather like a semantic = analyzer, which is extremely hard for any language, including Lojban.=

mu'o mi'e ianek
 
 

mu'o mi'e = ianek

--
You received this message because you are subscribed to the Google Groups "= lojban" group.
 To unsubscribe from this group and stop receiving emails from it, send an e= mail to lojban+un...@googlegroups.com.
To post to this group, send email to loj...@googlegroup= s.com.
Visit this group at http://groups.google.com/gro= up/lojban.
For more options, visit https://groups.google.com/d/optout.

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

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