On Sun, May 31, 2015 at 2:09 PM, Spheniscine (la zipcpi) <sphen...@gmail.com> wrote:I've not heard of that proposal. Wouldn't that just break all uses of {xy pa} when talking about the definitions of words?Those are "xy xi pa".The contexts where we don't want digits and lerfu to mix (e.g. ".abu za'u re'u cusku", "by re mei", "lo re bolci zo'u pa by xunre .i je pa by blanu", "xy xi pa dunda xy xi re xy xi ci" etc. are much much more common than the need for mixed strings, and having to use "boi" for those is a pain.
Besides, {me'o} still works, paralleling the use of strings for entry of ISO dates in programming languages. I just prefer {li} because
- It's shorter
- Dates and periods technically *are* numbers in a certain sense; arithmetic can be performed on them, despite the fact that in some ways they don't act like real-numbers, due to the varying length of months and years.
"me'o" and "li" are in the same selma'o, so the issue is the same for both.
--
You received this message because you are subscribed to the Google Groups "BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bpfk-list+...@googlegroups.com.
To post to this group, send email to bpfk...@googlegroups.com.
Visit this group at http://groups.google.com/group/bpfk-list.
For more options, visit https://groups.google.com/d/optout.
But how would "(n+1.3)^(3.15*r^2)" be expressed under this new xorxe's proposal then?
Agreed, the biggest question for me (beyond whether this is a good idea at all, zo'o zo'o nai) is what changes would be made to the grammar of LI?
li-clause <- LI-clause free* mex LOhO-clause? free*
Would it be able to take a pure-lerfu string, a pure-digit string, but not a mixture?
Or would we leave LI alone but create two new gadri selma'o that take pure-lerfu and pure-digit, respectively?
Ah, I didn't realize that "mex" was separate from "number+lerfu string". So I guess this is entirely orthogonal to la zipcpi's detri1 proposal, even though that thread got hijacked, .u'i.
I remain confused. {li pa} contains a number or mex, or both?
{li R2D2}?
{li pa su'i pa}? {li pa su'i abu}?
And which ones would be killed?
On 6/2/2015 4:54 PM, Jorge Llambías wrote:
Only "li R2D2", because "R2D2" would no longer be a valid lerfu-string.
So you are claiming that Lojban would not be usable to translate "Star Wars"?
If a string can be expressed or written, then it is inherently "valid" as a string, even if it meaningless.
(btw I guess we have to change the definition of {lerfu} if this goes through)
I agree the {abu boi reroi broda} thing is annoying, but... it's just a terminator. There are a lot of places in Lojban where you have to remember to un-elide terminators in certain situations. I'm not sure this one is annoying _enough_ to change the grammar.
This also seems to break (or make much less convenient) many usages of {jo'au}, mu'a one of the given examples {cylylypapi'epa jo'au}. You would have to use {lo'u} or something.
.u'i fegli milxe .i cikre lo pa mupli .iku'i lo lujmau na se cikre
Yes, "the first three cups" is still {ci boi pamoi kabri} and nothing can be done.
ma'oi JOI ji ma'oi VUhU
Le jeudi 4 juin 2015 04:50:08 UTC, la durka a écrit :ma'oi JOI ji ma'oi VUhU
.i la'a na.e.i mu'ibo tu'elo'uli pi'e 2015xiny 6xily 4xidy joi 4xijydyle'ucu simsa tu'a lo se studi be la zipcpigi'e ji'a drani ma'i lo cmaci jo'u lo gerna be fi zo pi'e noi cmavo ma'oi VUhU
I do not see any advantage to affecting LI...LOhO.
--
You received this message because you are subscribed to a topic in the Google Groups "BPFK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bpfk-list/GQ9Mnwieue0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bpfk-list+...@googlegroups.com.
One advantage would be not having two separate rules.
One advantage would be not having two separate rules.I don't see why that's such a problem. The grammar of LI...LOhO is already unique; that's why it's its own selma'o. And I don't think there are any serious attempts to combine it with any other selma'o, unlike sumtcita.
But seriously, if LI...LOhO is messed with, breaking the functionality of {me'o} (and {li'ai},
which under your proposal might actually be now needed to quote things like R2D2 {li'ai ry re dy re} instead of using it as a bare sumti),
we'd be forced to come up with a new selma'o just so we can quote arbitrary character strings without attaching {bu} to every nacle'u.
If I understand correctly, you are proposing that "operand" would no longer be "quantifier" or "lerfu-string" (among other things) but some new mixed entity. Whether this is a problem or not depends on your idea of simplicity, and whether or not it's worth striving for.
We now have to attach "bu" to every vowel, is that so different? Lerfu-strings are relatively rare in usage. I just don't see much need to have special rules for them.
On Tue, Jun 2, 2015 at 11:47 AM, Alex Burka <dur...@gmail.com> wrote:Agreed, the biggest question for me (beyond whether this is a good idea at all, zo'o zo'o nai) is what changes would be made to the grammar of LI?None. It only affects "number" and "lerfu-string" directly. li-clause remains the same:li-clause <- LI-clause free* mex LOhO-clause? free*
Would it be able to take a pure-lerfu string, a pure-digit string, but not a mixture?Among other things, yes. It still takes any mex.Or would we leave LI alone but create two new gadri selma'o that take pure-lerfu and pure-digit, respectively?We leave LI alone and we don't create anything new.
mu'o mi'e xorxes
--
You received this message because you are subscribed to the Google Groups "BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bpfk-list+...@googlegroups.com.
could you please provide the full set of changes to PEG?
number <- PA-clause (PA-clause / lerfu-word)* lerfu-string <- lerfu-word (PA-clause / lerfu-word)*Become:number <- PA-clause+ lerfu-string <- lerfu-word+
If I understand correctly, you are proposing that "operand" would no longer be "quantifier" or "lerfu-string" (among other things) but some new mixed entity. Whether this is a problem or not depends on your idea of simplicity, and whether or not it's worth striving for.The thing is in this particular context, it's causing so many problems. Simplicity is worth it up to a point, but not when it causes so many problems.
Don't get me wrong; I actually support your proposal. I'm just trying to come to a compromise for what I and others see is the part of it that causes the most problems, for the least benefit.
We now have to attach "bu" to every vowel, is that so different? Lerfu-strings are relatively rare in usage. I just don't see much need to have special rules for them.For one thing there is an experimental letteral series that uses a'y, e'y, i'y, o'y, and u'y (however, it's not been decided what to do with y'y under this system).
For another thing, it introduces opacity to the Lojban numeral system. They are embarrassingly simple compared to most other languages in that they are read out nacle'u by nacle'u. Having to figure out when {bu} needs to be added to them before reading any character string aloud ruins that simplicity.
It's like this. "abu, ebu" etc are treated as one "word" in people's minds, and represent the letters {a} and {e}. However, deciding when to use {pa} and when to use {pabu}, when both are rendered as the simple numeral {1}, introduces practical usage difficulties.
I guess I don't really see the many problems. I have fallen, and seen others fall, into the "abu za'u re'u cusku" trap and similar traps many times. I don't recall seeing things like "li 827266128281627362816Z" or even like "li R2D2" much in use.
Having to decide when digits can be mixed with letters and when they can't would introduce more usage difficulties in my opinion. I just don't see lerfu-strings being used that much, let alone ones containing digits.
On 9 Jun 2015 22:18, "Jorge Llambías" <jjlla...@gmail.com> wrote:
>
> On Mon, Jun 8, 2015 at 11:38 PM, <sphen...@gmail.com> wrote:
>> For one thing there is an experimental letteral series that uses a'y, e'y, i'y, o'y, and u'y (however, it's not been decided what to do with y'y under this system).
>
>
> We could have pa'y, re'y, ci'y as well if that was an issue (I am NOT proposing these).
Why not propose those? Or at least include them among candidate solutions.
--And.
Why not propose those? Or at least include them among candidate solutions.
On 10 Jun 2015 08:49, <sphen...@gmail.com> wrote:
>>
>> Why not propose those? Or at least include them among candidate solutions.
>
>
> It would have much the same problems as converting all numerals in character strings to {pabu} etc. would.
If I've read you right, the problem is that it's burdensome for speakers to have to remember whether they intend to 'refer' to a numeral or to a digit. But isn't such a distinction what you'd want from a logical language?
An advantage of _pa'y_ is that if speakers think of _abu_ or _a'y_ as one word, and that is good, and of _pabu_ as two, and that is bad, then _pa'y_ makes it all good.
--And.
The problems with pabu / pa'y are:
- They almost double the length of all character strings that are heavy in digits, e.g. my date system and Pierre's coordinate system.
- As for numeral/number distinction... the problem is that that very distinction is often hazy. Take for example the name of the game TIS-100; do those numbers actually mean "one hundred", or are they just an arbitrary string of numerals?