Received-SPF: neutral (google.com: 68.230.241.215 is neither permitted nor denied by best guess record for domain of lojbab@lojban.org) client-ip=68.230.241.215;
Message-ID: <51F2A607.2080302@lojban.org>
Date: Fri, 26 Jul 2013 12:38:31 -0400
From: "Bob LeChevalier, President and Founder - LLG" <lojbab@lojban.org>
Organization: The Logical Language Group, Inc.
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: lojban@googlegroups.com
Subject: Re: [lojban] MEX ROI, MEX MOI, MEX MAI
References: <51F15A4D.3030805@lojban.org> <4kdV1m00f56Cr6M01kda9k>
In-Reply-To: <4kdV1m00f56Cr6M01kda9k>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Spam_score: 0.0
X-Spam_score_int: 0
X-Spam_bar: /

Ian Johnson wrote:
> On Thu, Jul 25, 2013 at 1:03 PM, Bob LeChevalier, President and Founder
> - LLG <lojbab@lojban.org <mailto:lojbab@lojban.org>> wrote:
>
>     MOI on the other hand is already tied to MEX at the full grammar
>     level.  So I am not sure what it means to say that you cannot use
>     MEX with MOI.  Almost anything can be used with MOI if you first
>     turn it into a sumti, and then apply a ME conversion to that sumti.
>       You can of course turn a MEX into a sumti using LI, so "meli MEX"
>     with appropriate terminators should work with MOI.  I just tried it,
>     and you need either a lo'o or a me'u to terminate the li/me
>     construct before the moi.
>
> I consider ME LI MEX MOI to be a hack, not a proper solution. (Not that
> it was a bad idea when the goal was to get a YACC working, but it's a
> bad idea now, when the goal is to get a PEG working.) Simply MEX MOI
> *should* be fine.

There is no official goal to get a PEG working (and personally, I've 
never understood why anyone would want to).

The grammar is defined as a YACC grammar, and it works.

I understand that you consider it a hack, but it was in fact by design 
intention.

We considered MEX a distinct area of the grammar from predicates and 
sumti, and designed the conversion words and their delimiters to get 
from each to the other.

In that sense, the NON-requirement to explicitly mark a bare number with 
MOI was the exception (because it only used a string of cmavo of a 
single selma'o with no defined internal grammar)

Since a MEX often will end with a number, I actually would expect MEX 
MOI to rarely work without delimiting it.  And the rest of the time MEX 
would be likely to end with a lerfu, which could either be a number or a 
sumti.

Now it is plausible that once we had decided NOT to define the grammar 
of numbers (what is now PA was originally several selma'o with strict 
ordering rules), we could have moved MOI completely out of the 
preparser, and made the rule "quantifier_300"+MOI, which would allow a 
bracketed MEX or a number to precede MOI, and we could probably 
eliminate the me rule as superfluous, since NIhE and MOhE exist to turn 
sumti and bridi into MEX.  It might require a BOI after a number in some 
cases, and it still the MEX would still be delimited, but only by one 
bracket pair.

Since I haven't worked with YACC since the baseline, I'm too rusty to 
waste time trying.

I'm not sure what the usage is that would warrant a simpler MEX MOI 
construct, but I could envision accepting that approach to "fixing" it. 
  But that approach doesn't help with ROI, which is implicitly tied up 
in the preparser tense grammar.

lojbab
-- 
Bob LeChevalier    lojbab@lojban.org    www.lojban.org
President and Founder, The Logical Language Group, Inc.

-- 
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/groups/opt_out.