From nobody@digitalkingdom.org Wed Nov 05 16:07:25 2008 Received: with ECARTIS (v1.0.0; list lojban-list); Wed, 05 Nov 2008 16:07:26 -0800 (PST) Received: from nobody by chain.digitalkingdom.org with local (Exim 4.69) (envelope-from ) id 1KxsPE-00053F-Hp for lojban-list-real@lojban.org; Wed, 05 Nov 2008 16:07:25 -0800 Received: from fg-out-1718.google.com ([72.14.220.156]) by chain.digitalkingdom.org with esmtp (Exim 4.69) (envelope-from ) id 1KxsP5-00052B-0y for lojban-list@lojban.org; Wed, 05 Nov 2008 16:07:24 -0800 Received: by fg-out-1718.google.com with SMTP id e12so221603fga.0 for ; Wed, 05 Nov 2008 16:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=2nCqNvWVYp5bavw3DJ02s5Y9Vv58zLJL9lFTySuyhbs=; b=HelkiVFz5C+tDIIQhc+ymrJ5TDML5b/FLcIq8nasNPz+MwmzTlfdahJhGGe34LH0Ir Nhrf/jdI+fN5ffE9jRmF6huyWDBzVLiv0pE8n3I0igco4EyF2BxRNELdZ1YfZ7FiKTuI A1aVYtRYl9qXehGtZUZz3qjFvrTsP9qymL4As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rTHsvVNV2lATQcPA6sT/tRvSHvRNGnCJdYH12Vqc0fm0i2WnR9vyXiEDLiUgoPW0Gs G9yZrgmLwxSZ4PGUWFyBIoJ8fdURdaONdy+zcGZDhICRLfYRkY+gjpEfEh35iXmrlHVR wrKoBs6z1hADwat/nEJbnvcYVJlwzhzLoPoPw= Received: by 10.181.239.8 with SMTP id q8mr465302bkr.109.1225930029886; Wed, 05 Nov 2008 16:07:09 -0800 (PST) Received: by 10.181.1.5 with HTTP; Wed, 5 Nov 2008 16:07:09 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 01:07:09 +0100 From: "Daniel Brockman" To: lojban-list@lojban.org Subject: [lojban] Re: experimental cmavo in lojgloss. In-Reply-To: <737b61f30811050534i514b3fddv197b2a07a47655f9@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18960_5726679.1225930029867" References: <737b61f30811022128n9e8692evefaa820062d2a652@mail.gmail.com> <925d17560811031040t402eb7a9k31e0d61bf7ca3cea@mail.gmail.com> <925d17560811040350g2a04db8ewd2f34a8a43d96767@mail.gmail.com> <737b61f30811041523o3574936fp27dea91b6a058c26@mail.gmail.com> <737b61f30811050534i514b3fddv197b2a07a47655f9@mail.gmail.com> X-Google-Sender-Auth: 8e5e4beade2fde1a X-Spam-Score: 0.0 X-Spam-Score-Int: 0 X-Spam-Bar: / X-archive-position: 14930 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: daniel@gointeractive.se Precedence: bulk Reply-to: lojban-list@lojban.org X-list: lojban-list ------=_Part_18960_5726679.1225930029867 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Wed, Nov 5, 2008 at 2:34 PM, Chris Capel wrote: > On Wed, Nov 5, 2008 at 03:58, Daniel Brockman wrote: > > On Wed, Nov 5, 2008 at 12:23 AM, Chris Capel wrote: > >> Right, but it would still be unparsable. The problem is that the text > >> before it is ungrammatical, and so has to be ignored by the parser to > >> get the whole thing to parse, which requires that the parser > >> understand which words the lo'ai is nulling out. It can't be treated > >> half-way and have things still parse. > > > > The obvious way to implement {lo'ai .. sa'ai .. le'ai} in a parser is to > > just treat it as a self-contained construct that requires morphologically > > correct Lojban inside it, just like {lo'u .. le'u'}, and syntactically > > correct Lojban before it (just like everything else). > > How far before it? Up to the beginning of the sentence? The statement? > The {le'ai} construct doesn't care about ANYTHING else. However your parser works, that's how it works before {le'ai}. > > Of course it would require extraordinary methods to get things like > {kwama > > lo'ai kwama sa'ai klama le'ai} --- or why not {fsen.45ynl5tnerg98ehg4n su > > coi} --- to parse. It's not practical and not cost-efficient. The > {kjama} > > example falls in this category because {kj} is morphologically invalid. > > Hmm. I think you overestimate the difference in effort between the two > implementations. They both require the same tricks, just at a slightly > different level in the grammar. > What are you talking about? One implementation is self-contained; the other requires lots of weird backtracking and re-parsing and weird, weird stuff. > > What _would_ be useful and cost-efficient would be to get things like {.i > > .ai mi cakla sa'ai ckakla le'ai} to parse. > > Actually, this is the only useful one I can think of. If the text > isn't grammatical before the le'ai clause, then the user is probably > going to want to manually correct it anyway before feeding it to the > parser. This example happens to be both grammatical, and having nearly > the same parse tree as the corrected version (since the before and > after words are both brivla). > It doesn't matter if it has the same parse tree. It only matters that it PARSES IN ANY WAY. If it does, then the parser will be able to continue. If it doesn't, then the parser will die. -- Daniel Brockman daniel@gointeractive.se ------=_Part_18960_5726679.1225930029867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

On Wed, Nov 5, 2008 at 2:34 PM, Chris Capel <pdf23ds@gmail.com> wrote:
On Wed, Nov 5, 2008 at 03:58, Daniel Brockman <daniel@brockman.se> wrote:
> On Wed, Nov 5, 2008 at 12:23 AM, Chris Capel <pdf23ds@gmail.com> wrote:
>> Right, but it would still be unparsable. The problem is that the text
>> before it is ungrammatical, and so has to be ignored by the parser to
>> get the whole thing to parse, which requires that the parser
>> understand which words the lo'ai is nulling out. It can't be treated
>> half-way and have things still parse.
>
> The obvious way to implement {lo'ai .. sa'ai .. le'ai} in a parser is to
> just treat it as a self-contained construct that requires morphologically
> correct Lojban inside it, just like {lo'u .. le'u'}, and syntactically
> correct Lojban before it (just like everything else).

How far before it? Up to the beginning of the sentence? The statement?

The {le'ai} construct doesn't care about ANYTHING else.  However your parser works, that's how it works before {le'ai}.
 
> Of course it would require extraordinary methods to get things like {kwama
> lo'ai kwama sa'ai klama le'ai} --- or why not {fsen.45ynl5tnerg98ehg4n su
> coi} --- to parse.  It's not practical and not cost-efficient.  The {kjama}
> example falls in this category because {kj} is morphologically invalid.

Hmm. I think you overestimate the difference in effort between the two
implementations. They both require the same tricks, just at a slightly
different level in the grammar.

What are you talking about?  One implementation is self-contained; the other requires lots of weird backtracking and re-parsing and weird, weird stuff.
 
> What _would_ be useful and cost-efficient would be to get things like {.i
> .ai mi cakla sa'ai ckakla le'ai} to parse.

Actually, this is the only useful one I can think of. If the text
isn't grammatical before the le'ai clause, then the user is probably
going to want to manually correct it anyway before feeding it to the
parser. This example happens to be both grammatical, and having nearly
the same parse tree as the corrected version (since the before and
after words are both brivla).

It doesn't matter if it has the same parse tree.  It only matters that it PARSES IN ANY WAY.  If it does, then the parser will be able to continue.  If it doesn't, then the parser will die.

--
Daniel Brockman
daniel@gointeractive.se


------=_Part_18960_5726679.1225930029867-- To unsubscribe from this list, send mail to lojban-list-request@lojban.org with the subject unsubscribe, or go to http://www.lojban.org/lsg2/, or if you're really stuck, send mail to secretary@lojban.org for help.