PA^2 PA^3, but instead work like= =20 {ka'o}, repeating the operator for each instance. If something else needed= =20 to be conveyed, I expect {vei...ve'o} could be implemented to help out. mu'o mi'e djos --=20 You received this message because you are subscribed to the Google Groups "= lojban" group. To view this discussion on the web visit https://groups.google.com/d/msg/lo= jban/-/5OuWzk9S2b0J. To post to this group, send email to lojban@googlegroups.com. To unsubscribe from this group, send email to lojban+unsubscribe@googlegrou= ps.com. For more options, visit this group at http://groups.google.com/group/lojban= ?hl=3Den. ------=_Part_644_2072700.1321835574313 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

First of all, I= =92m extremely in favor of hierarchical selma=92o. That is, there are very = good reasons both for increasing the number of selma=92o (increased grammat= ical clarity) and for decreasing the number of selma=92o (less complicated = grammar). I believe the only good solution at this point is to introduce a = hierarchy, with subgrammars (lojbanized, paugerna). For instance, applied t= o this very thread, rather than make four completely new selma=92o (PA DUhE= CEhI PIhE) it seems we should make these be subclasses (lojbanized, pagsel= ma=92o) of an overarching group, say PA^ -- the idea being, PA^ represents = any combination of the four pagselma=92o which can be parsed on their own s= ubgrammar without influencing any grammar dealing with PA^. So PA^ would be= the thing to use when exemplifying sentence grammar with numbers in it (e.= g. explaining xorlo) while PA, etc. would be used for explaining numerical = grammar (e.g. THIS WHOLE THREAD). Even more succintly, PA^ would represent = the abstract thing we have been referring to as the =93number string=94.

Secondly, I would lik= e to more fully explain my issue with calling this right-grouping. What I m= ean to say is that we can define our pagselma=92o in a simple way such that= we get the exact (overall) behavior described at the beginning of the thre= ad with a left-grouping system. (Or, even better in my opinion, any-groupin= g.) To explain that, here is a Google Doc with the = full system as I see it. (Sorta-kinda like a =93if this were becoming offic= ial, here=92s a brief version of what I=92d try to put in the CLL and/or jb= ovlaste=94. This is another reason I really like the idea of hierarchical s= elma=92o -- it is a more easily searchable structure for word classes.)
Lastly, in order to no= t have to make this apparent in the Google Doc, I=92d like to directly addr= ess the =93separating strings=94 issue. There are two reasons we=92d need a= word to separating number strings: to separate the instances of the base P= A class, or to allow a more complicated paugerna.

(I'm keeping the following= text here so that you can see my old thoughts. I'm suddenly of a very diff= erent opinion on this issue. That is, I feel we don't need a new wor= d to serve this purpose, as th= e word .e is supposed to be able to serve this purpose just fine. The o= nly reason we'd need a different separate would be for a tanru-like semanti= cs, but what on Earth would that mean?)

F= or the former, that is to say {pa no so} means 109, but saying 10,9 would r= equire a separating word. Interestingly, this does not have any usefulness = except for saying =931000,1thousand=94 as {panonono xi=92e paki=92o} or =93= half, .5=94 as {fi=92o re xi=92e pi mu}, where {xi=92e} is the theoretical = separator. So, it would have, at best, a didactic purpose, and therefore wo= uld be better expressed as an equality or some other bridi. Thus, this usag= e is... lame.
For the lat= ter, we have very legitimate usage options. Once we can separate strings, t= his means we can also separate CEhI and PIhE (modifiers) from strings -- al= lowing us to give the modifying words different definitions for default arg= uments (or even have default behavior of a different paugerna). This I am strongly in favor of. It does make it= a little false to say, then, that =93fi=92u=94 is of pagselma=92o PIhE, si= nce it would be parsed as CEhI without a preceding value, but I think this = is the best way of doing it. (As someone else said above, we can tell a computer how to parse it without much = difficulty, and I think it=92s pretty intuitive anyway.)
(If your confused by me saying the versatil= e grammar requires a separator, then realize I have an understood requireme= nt of PA^ (number strings) in that they must have a grammar that makes unif= orm sense, defined in the Google Doc. For example, I demand that if {fi=92u= } is parseable as a PA^, then there must be a way to use it in any other sc= enario that could take a PA^, which would often require a separator of some= kind.)

<= font class=3D"Apple-style-span" face=3D"arial, sans-serif" size=3D"2">(end of text I don't actually agree w= ith)

Oh! And I just remembered, a long time ago there was a thread about m= ekso being relatively useless, and blah blah blah. I don't know what came o= f that, but if it were to be removed in any way, I would suggest merging so= me of the operators into PIhE, particularly things like {gei} and {ju'u}. H= owever, sometimes mekso applications can be very not intuitive and m= aybe would be modified (I hope!) to be more consistently straightforward if= they were to join these classes. For instance, I like the idea that these = PA^, have no modifiers that do PA^1 <modifier> PA^2 PA^3, but instead= work like {ka'o}, repeating the operator for each instance. If something e= lse needed to be conveyed, I expect {vei...ve'o} could be implemented to he= lp out.

<= font class=3D"Apple-style-span" color=3D"#000000" face=3D"arial, sans-serif= " size=3D"2">

= mu'o mi'e djos

--
You received this message because you are subscribed to the Google Groups "= lojban" group.
To view this discussion on the web visit https://groups.google.com/d/msg/lojban/-/5O= uWzk9S2b0J.
=20 To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegrou= ps.com.
For more options, visit this group at http://groups.google.com/group/lojban= ?hl=3Den.
------=_Part_644_2072700.1321835574313--