[lojban] Re: New PA-proposal

First of all, I’m extremely in favor of hierarchical selma’o. That is, there are very good reasons both for increasing the number of selma’o (increased grammatical clarity) and for decreasing the number of selma’o (less complicated grammar). I believe the only good solution at this point is to introduce a hierarchy, with subgrammars (lojbanized, paugerna). For instance, applied to this very thread, rather than make four completely new selma’o (PA DUhE CEhI PIhE) it seems we should make these be subclasses (lojbanized, pagselma’o) of an overarching group, say PA^ -- the idea being, PA^ represents any combination of the four pagselma’o which can be parsed on their own subgrammar 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 “number string”.

Secondly, I would like to more fully explain my issue with calling this right-grouping. What I mean to say is that we can define our pagselma’o in a simple way such that we get the exact (overall) behavior described at the beginning of the thread with a left-grouping system. (Or, even better in my opinion, any-grouping.) To explain that, here is a Google Doc with the full system as I see it. (Sorta-kinda like a “if this were becoming official, here’s a brief version of what I’d try to put in the CLL and/or jbovlaste”. This is another reason I really like the idea of hierarchical selma’o -- it is a more easily searchable structure for word classes.)

Lastly, in order to not have to make this apparent in the Google Doc, I’d like to directly address the “separating strings” issue. There are two reasons we’d need a word to separating number strings: to separate the instances of the base PA class, or to allow a more complicated paugerna.

For the former, that is to say {pa no so} means 109, but saying 10,9 would require a separating word. Interestingly, this does not have any usefulness except for saying “1000,1thousand” as {panonono xi’e paki’o} or “half, .5” as {fi’o re xi’e pi mu}, where {xi’e} is the theoretical separator. So, it would have, at best, a didactic purpose, and therefore would be better expressed as an equality or some other bridi. Thus, this usage is... lame.
For the latter, we have very legitimate usage options. Once we can separate strings, this means we can also separate CEhI and PIhE (modifiers) from strings -- allowing us to give the modifying words different definitions for default arguments (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 “fi’u” is of pagselma’o PIhE, since 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’s pretty intuitive anyway.)
(If your confused by me saying the versatile grammar requires a separator, then realize I have an understood requirement of PA^ (number strings) in that they must have a grammar that makes uniform sense, defined in the Google Doc. For example, I demand that if {fi’u} is parseable as a PA^, then there must be a way to use it in any other scenario that could take a PA^, which would often require a separator of some kind.)

Oh! And I just remembered, a long time ago there was a thread about mekso being relatively useless, and blah blah blah. I don't know what came of that, but if it were to be removed in any way, I would suggest merging some of the operators into PIhE, particularly things like {gei} and {ju'u}. However, sometimes mekso applications can be very not intuitive and maybe 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 else needed to be conveyed, I expect {vei...ve'o} could be implemented to help out.