Is there any demand for LoCCan3?

[gleki]

Several recent messages mentioned the need for LoCCan3.

I wonder is there really any demand for it?

lojban.org wiki mentions nothing special.

1. Fewer cmavo (but you are free to use fewer cmavo in current lojban)

2. There should be new cmavo for individuals, sets and masses

3. connectives

4. anaphoric pronouns

(sorry, I didn't understand a word in #2,3,4, can you explain it to me in plain language?).

5. gismu with another number of sumti (but you are free not to use some sumti, to use sumtcita etc.)

Anyway, even if so is there any need to break existing language?

[la .lindar.]

It's come up a few times.

https://en.wikipedia.org/wiki/Anaphora_(linguistics)

I think we're working on the rest.

It's a theoretical next-step language, but I don't see it happening any time soon since we're changing up our game.

[gleki]

Do you think this next-step language will still be compatible with the current baseline?

[Jonathan Jones]

No. It would be an entirely new language, and no more compatible with Lojban than Lojban is with Loglan.

--
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/-/WuHVVjYqa8EJ.

To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .aionys.

.i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o
(Come to the Dot Side! Luke, I am your father. :D )

[gleki]

Let's discuss it now ))).

After reading the article I want new language even less.

The monkey took the banana and ate it. 

Pam went home because she felt sick.  

The dog ate the bird and it died.  (!!!!!!!!!!!)

In each case I can use {ta} and the context will decide who felt sick (the house or Pam) and who died (the dog or the bird).

In other cases  vo'a, ko'a can solve the problem.

{sei} can be problematic for me but I hope CLL 1.1 will explain it.

I can think of no other cases of anaphora.

And it's still am mystery for me what can be done with

2. There should be new cmavo for individuals, sets and masses

3. new design of connectives

On Monday, July 2, 2012 10:26:12 AM UTC+4, la .lindar. wrote:

[Jonathan Jones]

On Mon, Jul 2, 2012 at 3:41 AM, gleki <gleki.is...@gmail.com> wrote:

Let's discuss it now ))).

After reading the article I want new language even less.

The monkey took the banana and ate it. 

Pam went home because she felt sick.  

The dog ate the bird and it died.  (!!!!!!!!!!!)

In each case I can use {ta} and the context will decide who felt sick (the house or Pam) and who died (the dog or the bird).

In other cases  vo'a, ko'a can solve the problem.

{sei} can be problematic for me but I hope CLL 1.1 will explain it.

I can think of no other cases of anaphora.

And it's still am mystery for me what can be done with

2. There should be new cmavo for individuals, sets and masses

3. new design of connectives

Well, the connectives issue is, as far as I'm aware, that there's too many of them, and some are very poorly defined- we don't know exactly how they interact.

I believe .xorxes. created a proposal that addressed the first issue at least. I remember reading it, and deciding that I rather liked the idea. Let me see if I can find it, I know it's on the Lojban site.
 

On Monday, July 2, 2012 10:26:12 AM UTC+4, la .lindar. wrote:

It's come up a few times.

https://en.wikipedia.org/wiki/Anaphora_(linguistics)

I think we're working on the rest.

It's a theoretical next-step language, but I don't see it happening any time soon since we're changing up our game.

--

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/-/ZqkHTaoWCKAJ.

To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Jonathan Jones]

Ah ha! I have found it. It's actually in an topic on the main Lojban group entitled "The Mad Proposals": https://groups.google.com/forum/?fromgroups#!topic/lojban/ExtEumbYoQg

[gleki]

On Monday, July 2, 2012 2:01:45 PM UTC+4, aionys wrote:

Ah ha! I have found it. It's actually in an topic on the main Lojban group entitled "The Mad Proposals": https://groups.google.com/forum/?fromgroups#!topic/lojban/ExtEumbYoQg

ki'anaisai kie'sai

.i .a'o you guys from BPFK'2012+ will set those connective free and make this language (not any mythical loccan3) more simple while not breaking the baseline.

 

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .aionys.

.i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o
(Come to the Dot Side! Luke, I am your father. :D )

[Bob LeChevalier, President and Founder - LLG]

gleki wrote:
> Several recent messages mentioned the need for LoCCan3.
> I wonder is there really any demand for it?

> lojban.org wiki mentions <http://www.lojban.org/tiki/New+LoCCan>nothing

> special.
>
> 1. Fewer cmavo (but you are free to use fewer cmavo in current lojban)
> 2. There should be new cmavo for individuals, sets and masses
> 3. connectives
> 4. anaphoric pronouns
> (sorry, I didn't understand a word in #2,3,4, can you explain it to me
> in plain language?).
> 5. gismu with another number of sumti (but you are free not to use some
> sumti, to use sumtcita etc.)
>
> Anyway, even if so is there any need to break existing language?

The topic has come up intermittently for 25 years. There has been some
support for directed evolutionary change of Lojban (i.e. "reform", of
the sort xorxes often supports) but not much for redesign. There has
been a little support for exploring what it would take to have a more
rigorously "logical" language (look through the archives for writings of
And Rosta for more)

If there has been any agreement regarding a possible redesign (and I'm
not sure there has) it has been that any such redesign probably would
not be a real improvement nor be a language that would succeed. Any
major change would be a traumatic schism of the sort that hit Esperanto
and Ido.

The bottom line is that any improvement would have to offer an
unquestioned benefit worth the very significant effort of relearning (in
a community, many of whom are not especially skilled at learning
languages in the first place), and the loss of the last 25 years worth
of usage and history, all of which would be invalidated. Consider the
person-years of effort it would take to get as far as we have, which is
great for an artificial language, but really isn't all that far, by the
standards of natural languages.

I have occasionally suggested that any redesign should be done solely by
fluent speakers of Lojban with all discussions conducted in that
language. Only such collective mastery of Lojban would provide the
insight that would be required to make a better "logical" language. But
even such an attempt would likely be unsuccessful.

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

[gleki]

I got your point. Thanks.

But xorxes's ideas looked like an addition to the language or like alternative realisations, not necessarily breaking the baseline.

May be we can reconsider his ideas trying to find other better ways within the baseline to remove the need in learning many cmavo (therefore marking existing connectives as obsolete but still valid), using only existing rules and therefore making learning spoken lojban a bit easier for nintadni ?

[Bob LeChevalier, President and Founder - LLG]

gleki wrote:
> I got your point. Thanks.
>
> But xorxes's ideas looked like an addition to the language or like
> alternative realisations, not necessarily breaking the baseline.

Any changes including additions to the grammar, cmavo, or gismu, would
"break the baseline", though additions are not as potentially difficult
as changes or deletions, which is why we made provision for experimental
cmavo. lujvo and fu'ivla are not baselined, so the expected change in
the language would be growth in those two categories.

If English is any standard, we probably need a lexicon in excess of
20,000 words before the language starts suffering from redundancy enough
to think about "deletion".

Formally, a baseline means that there are no changes at all for a period
of time, and any proposals are fully documented before being considered
for approval (which would mean change-pages for CLL and other standard
materials, as well as a documented summary discussion of the pros and
cons for the change).

> May be we can reconsider his ideas trying to find other better ways
> within the baseline to remove the need in learning many cmavo (therefore
> marking existing connectives as obsolete but still valid), using only
> existing rules and therefore making learning spoken lojban a bit easier
> for nintadni ?

I see no problem with teaching a subset of the language to nintadni.
Indeed, I rather doubt that most people need to learn MEX, even if it
isn't "obsolete", and other parts of the language (term-sets) are of
minor importance in current usage. Of course, in future, things not
used much now may become a large importance. The idea was to provide
tools for growth so as not to constrain the possibilities, while also
STRONGLY avoiding the tendency of artificial language aficionados to
"redesign" things which has killed the vast majority of projects that
ever got far enough to see real usage.

I haven't objected to any use of experimental cmavo, though I myself
don't try to read text with experimental cmavo, since I don't keep track
of what has been proposed (and I have never been any good at using the
wiki to get info, much less contributing to it). But my own
proclivities in reading or usage are probably irrelevant, since I
contribute so little in those arenas these days.

But I really want to see the language as it is well-documented and
used-as-documented for a substantial period before I support further
fiddling with the language definition. My long-standing policy was a 5
year period, and then Lojban-only discussions of any proposed changes,
though I am not sure how much support there is for those concepts, and
the decision will not be up to me.

[John E Clifford]

LoCCan3 has been for more than 20 years (and before that there was Loglan 2.0) a repository for noting flaws perceived in Lojban (and before that Loglan) and for suggested solutions and other improvements (read scare quotes where you will).  The active content has varied over the years: no one is hot for adding or dropping phonemes at the moment, for example.  But a few items have endured, usually connected with perceived problems.

0.  A complete redo of the vocabulary (obviously not back-compatible).  The present vocab clusters in some phonetic spaces and leaves others bare, increasing the likelihood of confusion in noisy environments (if Lojban is ever used in one) and making it harder to find fragments for constructing compounds and related cmavo.  The only reason for the present word list is the claimed ease of learning, a claim that has never been tested on even English speakers, let alone Chinese or other languages or relevant multilinguals.  The evidence presented is either intuitive or anecdotal and these are countered by anecdotal difficulties ("false friends" they used to be called).  The revamp includes a revision of the definitions, which could be done separately (with a bit more compatibility) to make the definitions simpler (generally fewer places, with many places that occur in many definitions but are rarely used spun off to prepositions) and more uniform (all words of the same sort (you are keeping your supply of scare quotes running, I hope) would have the same pattern of places).  A general shake down of the cmavo system is also part of this, sharpening definitions, clarifying roles, getting rid of detritus, relieving confusion pressure, etc.  For the most part, this is not Lojban at all but the beginnings of a real third generation from Loglan.  So not going to happen until the next charismatic nut-case comes along.

1. Anaphora.  The logical ideal is a way to refer back to any previously mentioned thing unambiguously and transparently from anywhere in the later discourse.  Practically impossible with pronouns, unless every noun is assigned a carrier at birth (and there are problems even with that).  Loglan can come remarkably close, but the system barely works with written text and is just not practical in spoken language beyond very short intervals.  The usable Lojban techniques, official and not, work as well as the unofficial for the most part but are also of limited scope.  The rule "Repetition is also anaphora" seems the best way to go, though even it has to be used carefully in some   Cataphora (referring to something about to be mentioned) is always short scope and can be eased by mentioning it now already.

2.  Words for individuals and sets and masses arose out of the muddle, inherited from Loglan and not much tidied up in CLL, about what exactly 'lo broda' referred to.  The old underlying logic had only individuals, some of which were sets that contained other individuals (or not).  The problem then was to deal with groups that did not behave like sets in set theory but could still go in for individual variables.  For some reason, the notion that ordinary sets could take properties in different ways from the usual ways for sets did not occur to anyone, so this remained a problem.  Until xorxes found a book about plural reference/instantiation.  According to this, a singular noun could refer to several things at once and a singular variable could be simultaneously instantiated to several things at once.  Conceptually differently, but formally the same, sets could be Lesniewskian rather than Cantorian, so that getting to the members of a set is much easier (as is talking about what happens).  Once 'lo broda' was taken to refer to an L-set of brodas, much of the rest fell into place.  Because the theory is also of the part-whole relation, it is sometimes necessary to distinguish the relevant individuals (ones with no relevant parts) and also to be able to talk about wholes (L-sets) in the abstract way that one normally talks about C-sets.  This means that some of the gadri need redefinition (or clarification of the given definitions).  There are also some residual problems with 'lo' left over from Loglan that need sorting out.  None of this has much affect on current or past text.

3,  The original four logical connectives, and their derivatives (often more interesting) and the handful of non-logical ones have multiplied sixfold or more.  As the language is built, these are needed to preserve the underlying logical structure, to provide a way to get back to the underlying simple sentences connected sententially  from the given complex sentence involving connected terms or predicates or bridi tails or whatever.  The quest here has been to find a simpler way of marking these transformations without needing a whole new vocabulary at each stage.  The fact that the reconstruction process involved is not proven to be correct also needs some looking at.  This may be a minor matter of reinterpreting given forms or it may take a thorough reworking of the connective parts of the grammar.

4.  RHE.  Though the grammatical right-hand end problems are mainly solved (with the constant danger of misuse leading to your saying something quite different from what you meant), the logical ones are less well dealt with (the "get back to the formula" problem seen in 3).  So far, informal conventions seem to be in place and there are some cmavo for doing some of these jobs.  But they are rarely used and not well described.  They do not form clear groups in the cmavo lists, though grouping them might not be a problem (and the fact that they are very different might be an advantage). 

That is what LoCCan3 actively contains at the moment.

---

From: gleki <gleki.is...@gmail.com>
To: loj...@googlegroups.com
Sent: Monday, July 2, 2012 4:41 AM
Subject: [lojban] Re: Is there any demand for LoCCan3?

--

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/-/ZqkHTaoWCKAJ.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[.arpis.]

(Not interested in actually changing lojban, just getting my thoughts out, etc.)

One of the things that drew me to lojban was the fact that the gismu relationships were carefully defined (e.g. [almost?] every one that could have a "by standard" place did). I liked the fact this was so intrinsically part of the definition of the words. However, I recognize that such places are almost never used and make place structure more difficult to remember. It would be unfortunate to factor these places out to BAI (e.g. {ma'i}) because they would no longer be intrinsic to the relation. I wonder, though, if brivla could have "hidden" places which are inaccessible through FA and SE but are accessible through BAI, but are still intrinsic, so are by default filled with {zo'e} rather than {zi'o} as is the case for unrelated BAI.

--
mu'o mi'e .arpis.

[Bob LeChevalier, President and Founder - LLG]

John E Clifford wrote:
> 0. A complete redo of the vocabulary (obviously not back-compatible).
> The present vocab clusters in some phonetic spaces and leaves others
> bare, increasing the likelihood of confusion in noisy environments (if
> Lojban is ever used in one)

The Lojban design actually did take into account the possibility of
noisy environments. Perhaps not as much as some would prefer, but it
certainly was a factor. Primary place where this is evident is the
numerals, 0-hexF, which differ maximally in both consonant and vowel.
No gismu differs from another merely by a voiced/unvoiced contrast in
one consonant, etc. I actually did ask someone to do further research
on the matter of redundancy, but that was one of the cases where someone
volunteered and then disappeared.

Perhaps we could have gone further, but it isn't clear that we could
have done any better, without ignoring other larger priorities.

> The only reason for the
> present word list is the claimed ease of learning, a claim that has
> never been tested on even English speakers,

Actually, there was a limited test (I think I have a dozen or so data
sets), but the data has never been analyzed, because it seems that no
one but me ever cared. My knowledge of statistics wasn't that good to
begin with, and has accumulated 40 years of rust since college.

> let alone Chinese or other languages or relevant multilinguals.

We do have anecdotal reports from Chinese natives that find the
words/memory hooks much more learnable than Esperanto, but that isn't
saying much.

> The revamp includes a
> revision of the definitions, which could be done separately (with a bit
> more compatibility) to make the definitions simpler (generally fewer
> places, with many places that occur in many definitions but are rarely
> used spun off to prepositions) and more uniform (all words of the same
> sort (you are keeping your supply of scare quotes running, I hope) would
> have the same pattern of places).

The current place structures already reflect a couple generations of
such revisions made before the baselining, as compared with TLI Loglan.

> A general shake down of the cmavo
> system is also part of this, sharpening definitions, clarifying roles,
> getting rid of detritus, relieving confusion pressure, etc. For the
> most part, this is not Lojban at all but the beginnings of a real third
> generation from Loglan.

Correct.

> So not going to happen until the next
> charismatic nut-case comes along.

Gee thanks! No one ever accused me of being charismatic before.

> 2. Words for individuals and sets and masses arose out of the muddle,
> inherited from Loglan and not much tidied up in CLL, about what exactly
> 'lo broda' referred to. The old underlying logic had only individuals,
> some of which were sets that contained other individuals (or not). The
> problem then was to deal with groups that did not behave like sets in
> set theory but could still go in for individual variables. For some
> reason, the notion that ordinary sets could take properties in different
> ways from the usual ways for sets did not occur to anyone, so this
> remained a problem. Until xorxes found a book about plural
> reference/instantiation. According to this, a singular noun could refer
> to several things at once and a singular variable could be
> simultaneously instantiated to several things at once. Conceptually
> differently, but formally the same, sets could be Lesniewskian rather
> than Cantorian, so that getting to the members of a set is much easier
> (as is talking about what happens). Once 'lo broda' was taken to refer
> to an L-set of brodas, much of the rest fell into place. Because the
> theory is also of the part-whole relation, it is sometimes necessary to
> distinguish the relevant individuals (ones with no relevant parts) and
> also to be able to talk about wholes (L-sets) in the abstract way that
> one normally talks about C-sets. This means that some of the gadri need
> redefinition (or clarification of the given definitions). There are
> also some residual problems with 'lo' left over from Loglan that need
> sorting out. None of this has much affect on current or past text.

I suspect that you may have provided or at least hinted at an
explanation of xorlo that might make sense to me, if I were capable of
taking it in right now. I've never heard this stuff about Lesniewskian
or Cantorian, and have no clue what you are referring to, but maybe
someday this would make sense. Examples might help.

> That is what LoCCan3 actively contains at the moment.

I suspect that someone reading through Rosta's stuff would find a few
more topics.

[Jorge Llambías]

On Mon, Jul 2, 2012 at 5:35 PM, Bob LeChevalier, President and Founder
- LLG <loj...@lojban.org> wrote:
>
> The Lojban design actually did take into account the possibility of noisy
> environments. Perhaps not as much as some would prefer, but it certainly
> was a factor. Primary place where this is evident is the numerals, 0-hexF,
> which differ maximally in both consonant and vowel.

Not the best example. Numerals "re" and "rei" differ minimally.

mu'o mi'e xorxes

[Jorge Llambías]

On Mon, Jul 2, 2012 at 3:35 PM, .arpis. <rpglover...@gmail.com> wrote:
>
> One of the things that drew me to lojban was the fact that the gismu
> relationships were carefully defined (e.g. [almost?] every one that could
> have a "by standard" place did).

How do you determine which ones couldn't have a "by standard" place?
It seems to me that every relationship could have a "by standard"
place added, so those gismu that have an explicit one are only a small
fraction of those that could have it.

[.arpis.]

All of them could have a "by standard" place added, so both {ta karce ma'i la .niu.iork.} and {ta cladakyxa'i ma'i la .niu.iork.} would have the current meanings, but {ta karce} would mean the same thing as {ta karce ma'i zi'o} while {ta cladakyxa'i} would mean the same thing as {ta cladakyxa'i ma'i zo'e} and {ta cladadyxa'i fu la .niu.iork.} would have a non-existent place filled.

Apologies if I misunderstand the meaning of "BAI zi'o"

I've been thinking too much about math recently, so the way I view it might not be illuminating to anyone, but I view the current state of affairs as selbri having infinitely many places, the "numbered" of which are filled with {zo'e} by default and the others of which are filled with {zi'o} by default and I'm suggesting removing some numbered places that correspond to the same thing as a BAI place and filling the BAI place with {zo'e}.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[gleki]

On Monday, July 2, 2012 10:03:32 PM UTC+4, clifford wrote:

LoCCan3 has been for more than 20 years (and before that there was Loglan 2.0) a repository for noting flaws perceived in Lojban (and before that Loglan) and for suggested solutions and other improvements (read scare quotes where you will).  The active content has varied over the years: no one is hot for adding or dropping phonemes at the moment, for example.  But a few items have endured, usually connected with perceived problems.

0.  A complete redo of the vocabulary (obviously not back-compatible).  The present vocab clusters in some phonetic spaces and leaves others bare, increasing the likelihood of confusion in noisy environments (if Lojban is ever used in one) and making it harder to find fragments for constructing compounds and related cmavo.  The only reason for the present word list is the claimed ease of learning, a claim that has never been tested on even English speakers, let alone Chinese or other languages or relevant multilinguals.  The evidence presented is either intuitive or anecdotal and these are countered by anecdotal difficulties ("false friends" they used to be called).  The revamp includes a revision of the definitions, which could be done separately (with a bit more compatibility) to make the definitions simpler (generally fewer places, with many places that occur in many definitions but are rarely used spun off to prepositions) and more uniform (all words of the same sort (you are keeping your supply of scare quotes running, I hope) would have the same pattern of places).  A general shake down of the cmavo system is also part of this, sharpening definitions, clarifying roles, getting rid of detritus, relieving confusion pressure, etc.  For the most part, this is not Lojban at all but the beginnings of a real third generation from Loglan.  So not going to happen until the next charismatic nut-case comes along.

Ubykh has 84 phonemic consonants. As J. Quijada writes "Ubykh single-word sentence wan-tw-aan - "they give you to him" ... contains six phonemes, each of which is a separate morpheme.... If such single-phoneme morphemes are good enough for real-world natural languages, they’re good enough for Ithkuil."

Which means that you can never invent a sound system suitable for everyone but at the same time even most complex phoneme inventory might be naturalistic. In the long run you might end in Piraha-style conlang which has around 7 consonants

1. Anaphora.  The logical ideal is a way to refer back to any previously mentioned thing unambiguously and transparently from anywhere in the later discourse.  Practically impossible with pronouns, unless every noun is assigned a carrier at birth (and there are problems even with that).  Loglan can come remarkably close, but the system barely works with written text and is just not practical in spoken language beyond very short intervals.  The usable Lojban techniques, official and not, work as well as the unofficial for the most part but are also of limited scope.  The rule "Repetition is also anaphora" seems the best way to go, though even it has to be used carefully in some   Cataphora (referring to something about to be mentioned) is always short scope and can be eased by mentioning it now already.

So no problem in the current Lojban? :)

2.  Words for individuals and sets and masses arose out of the muddle, inherited from Loglan and not much tidied up in CLL, about what exactly 'lo broda' referred to.  The old underlying logic had only individuals, some of which were sets that contained other individuals (or not).  The problem then was to deal with groups that did not behave like sets in set theory but could still go in for individual variables.  For some reason, the notion that ordinary sets could take properties in different ways from the usual ways for sets did not occur to anyone, so this remained a problem.  Until xorxes found a book about plural reference/instantiation.  According to this, a singular noun could refer to several things at once and a singular variable could be simultaneously instantiated to several things at once.  Conceptually differently, but formally the same, sets could be Lesniewskian rather than Cantorian, so that getting to the members of a set is much easier (as is talking about what happens).  Once 'lo broda' was taken to refer to an L-set of brodas, much of the rest fell into place.  Because the theory is also of the part-whole relation, it is sometimes necessary to distinguish the relevant individuals (ones with no relevant parts) and also to be able to talk about wholes (L-sets) in the abstract way that one normally talks about C-sets.  This means that some of the gadri need redefinition (or clarification of the given definitions).  There are also some residual problems with 'lo' left over from Loglan that need sorting out.  None of this has much affect on current or past text.

Clarification is great. Again sounds quite reasonable within the current language.

3,  The original four logical connectives, and their derivatives (often more interesting) and the handful of non-logical ones have multiplied sixfold or more.  As the language is built, these are needed to preserve the underlying logical structure, to provide a way to get back to the underlying simple sentences connected sententially  from the given complex sentence involving connected terms or predicates or bridi tails or whatever.  The quest here has been to find a simpler way of marking these transformations without needing a whole new vocabulary at each stage.  The fact that the reconstruction process involved is not proven to be correct also needs some looking at.  This may be a minor matter of reinterpreting given forms or it may take a thorough reworking of the connective parts of the grammar.

.i'a

 

4.  RHE.  Though the grammatical right-hand end problems are mainly solved (with the constant danger of misuse leading to your saying something quite different from what you meant), the logical ones are less well dealt with (the "get back to the formula" problem seen in 3).  So far, informal conventions seem to be in place and there are some cmavo for doing some of these jobs.  But they are rarely used and not well described.  They do not form clear groups in the cmavo lists, though grouping them might not be a problem (and the fact that they are very different might be an advantage). 

Again clarification. That's the job  of lojbanists, not loccan3-ists.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

 

And therefore

> So not going to happen until the next 

> charismatic nut-case comes along.  

ban such person immediately from this group when [s]he appears! vau zo'o

[John E Clifford]

& has been missing a while, so his ideas are not in the current files.  They were iirc mainly technical and philosophic, so not (as) relevant to structural questions.  (I hope this remark is inaccurate enough to get & to reenter the lists.)

---

From: "Bob LeChevalier, President and Founder - LLG" <loj...@lojban.org>
To: loj...@googlegroups.com
Sent: Monday, July 2, 2012 3:35 PM
Subject: Re: [lojban] Re: Is there any demand for LoCCan3?

-- You received this message because you are subscribed to the Google Groups "lojban" group.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsub...@googlegroups.com.

[And Rosta]

John E Clifford, On 03/07/2012 17:36:

> & has been missing a while, so his ideas are not in the current files. They were iirc mainly technical and philosophic, so not (as) relevant to structural questions. (I hope this remark is inaccurate enough to get & to reenter the lists.)

Okay. So I'll address Gleki's question about "Is there any demand for LoCCan3", and also this, because Jonathan could equally well have asked the same question of me:
Jonathan Jones, On 01/07/2012 22:59:
> John, I was wondering. It seems to me that you rarely contribute
> anything to the community, and when you do, it is usually to
> criticize, to point out what you perceive to be flaws in Lojban. You
> also frequently express your opinion as to the need for a LoCCan3, as
> you put it. From my experience, it seems that you don't like Lojban.
>
> Now, I may be wrong about all of this, and I wouldn't be surprised if
> you contribute(d) a great deal that I'm unaware of. But assuming the
> above is true, and these are your feelings, why are you hear? I am
> truly curious to know why you maintain a presence in something it
> seems you not only do not care about, but apparently actively
> dislike, especially given your recent comment about being unable to
> keep a straight face in discussing Lojban.

I have for decades (more than two, not quite three, so far -- i.e. all my adult life) been very interested in the idea of there existing a certain sort of loglang and of this loglang being available to the world for use. I think it would be a boon for the world to have recourse to an ergonomically usable unambiguous language. Not everybody interested in Loglan--Lojban is interested in any sort of loglang, but it does seem as though quite a few people involved in Loglan--Lojban have been interested in a loglang, and also as though many of those interested in loglangs, especially ones with a community of sponsors, gravitate towards Loglan--Lojban.

I define a loglang as one that can unambiguously encode any explicit predicate logic formula in a way that is no less concise than the way natlangs would express the formula (with much greater ambiguity and leaving much more to be glorked from context). The relevance of the concision requirement is firstly that without it, the gain in clarity is not necessarily worth the effort of greater verbosity; rather, the goal is to up the clarity-to-verbosity ratio. And secondly, designing a language that can unambiguously encode any explicit predicate logic formula is trivially easy; it's only the concision requirement that makes the challenge difficult (or maybe impossible). Not everybody defines their sought-for loglang by these criteria. For example, John Clifford and Martin Bays are very preoccupied with having a highly specified semantics for the loglang, which is something I'm rather unsympathetic to.

Considered *as a loglang (in my definition of that term)*, Lojban is a complete failure, though it must be borne in mind that it wasn't fundamentally designed to be a loglang; the loglang aspect is more part of its (undeserved) reputation than its essence. (I should clarify that, once the BPFK does its work, which basically involves Robin wielding the political muscle and Xorxes wielding the intellectual muscle, Lojban would succeed in being logically unambiguous. The failure is to meet the (never aimed-for) criterion of concision.) (I should also note that Lojban has been a success relative to the goals of the founders of Lojban, namely to create a public-domain stable "finished" version of Loglan around which a community of users can grow.)

I'm here (on this list) partly because I've been part of the community for over 20 years, and at certain times have been the most active participant, so I feel a sense of (always marginalized) belonging. But also I'm here because I think there's a chance of a genuine loglang coupled with a community of sponsors emerging from the Loglan--Lojban community. There might come a time when enough folk that think as I do have gravitated hither that some sort of critical mass is formed and work on an ergonomically usable loglang is begun.

It's easy to think of ways of drastically improving on the Lojban design. For example, discard rafsi, make all gismu CCV -- becomes conciser and easier to learn in one go. Or discard almost all selmaho, default to Polish notation syntax, and you have something much conciser, much more easy to learn, much more easy to parse. I suppose that even these changes are so drastic that they'd amount to discarding the current Loglan--Lojban entirely and starting over, but I think a complete redesign is anyway necessary because of the one fundamental design challenge of a loglang, which is the challenge of representing where two argument-places have the same value (e.g. in "John laughed and sneezed", where the argument-place of John(), of Laugh() and of Sneeze() have the same value): specifically, the challenge is to represent that in a concise and human-usable way (bearing in mind that a normal sentence might involve dozens of groups of argument-places that have the same value). You c
ould call this loglang "LoCCan3", but, unlike John Clifford's vision, it couldn't be achieved by incremental revisions to LoCCan2.

--And.

[MorphemeAddict]

To return to the original question, I would like a new version of Loglan/Lojban that fixed the perceived problems associated with those two languages. I don't know what my solution would look like (well, I have a version, but it's only a relex of the gismu, so I don't normally count it). 

And the sooner the better. 

stevo

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

[John E Clifford]

Hey &, long time no see, etc. Well, we are less far apart than a casual reading might suggest.  I did recall (incorrectly, obviously) that you were into tight semantics as well, but the rest fits in nicely with the problem set from of old.  Wrapped up, as I am professionally, in variables, I tend to see the same-argument problem as just a matter of assigning variables at the right time and place, but that over looks the fact that variables are an essentially inefficient (for purposes other than precision, at least) way of doing things.  As a result, I tend to see the major problems as RHE and un/packing.  To be sure, for strict concision  (syllable counts, say), vocabulary is a problem, since the shortest legitimate Lojban content words are already as long as the average English ones.  But going to CCV, for example, raises other problems which, while not strictly relevant to the formal adequacy of the language as a loglang, cut into its practical applications sharply.  The RHE and un/packing problems go together, because, even if there is a successful parsing program for Lojban, it is not at all clear that the isolated elements will be identical or determinately mapped to the logical elements.  From the point of view of a loglang, they are also a problem for it is with them that the greatest amount of apparent parsley comes up.  While RHE markers can be dropped with wild abandon, some cannot --- and every one that is not a step away from concision (and back. alas, toward the the state in actual predicate logic, which puts EVERYTHING in, one way or another).  So, in one sense, the first step toward a good loglang is to improve FOL++ in the concision direction, toward combinatorics, say (not that that always is either concise nor clear).

I do think there can be incremental improvements within Lojban toward a viable spoken FOL, guaranteed accurate, and not so prolix as to be unusable (people do use German after all, when English is available -- and Chinese).

---

From: And Rosta <and....@gmail.com>
To: loj...@googlegroups.com
Sent: Friday, July 6, 2012 3:45 PM
Subject: Re: [lojban] Re: Is there any demand for LoCCan3?

[la gleki]

On Saturday, July 7, 2012 12:45:26 AM UTC+4, And Rosta wrote:

John E Clifford, On 03/07/2012 17:36:
> & has been missing a while, so his ideas are not in the current files. They were iirc mainly technical and philosophic, so not (as) relevant to structural questions. (I hope this remark is inaccurate enough to get & to reenter the lists.)

Okay. So I'll address Gleki's question about "Is there any demand for LoCCan3", and also this, because Jonathan could equally well have asked the same question of me:
Jonathan Jones, On 01/07/2012 22:59:
> John, I was wondering. It seems to me that you rarely contribute
> anything to the community, and when you do, it is usually to
> criticize, to point out what you perceive to be flaws in Lojban. You
> also frequently express your opinion as to the need for a LoCCan3, as
> you put it. From my experience, it seems that you don't like Lojban.
>
> Now, I may be wrong about all of this, and I wouldn't be surprised if
> you contribute(d) a great deal that I'm unaware of. But assuming the
> above is true, and these are your feelings, why are you hear? I am
> truly curious to know why you maintain a presence in something it
> seems you not only do not care about, but apparently actively
> dislike, especially given your recent comment about being unable to
> keep a straight face in discussing Lojban.

I have for decades (more than two, not quite three, so far -- i.e. all my adult life) been very interested in the idea of there existing a certain sort of loglang and of this loglang being available to the world for use. I think it would be a boon for the world to have recourse to an ergonomically usable unambiguous language. Not everybody interested in Loglan--Lojban is interested in any sort of loglang, but it does seem as though quite a few people involved in Loglan--Lojban have been interested in a loglang, and also as though many of those interested in loglangs, especially ones with a community of sponsors, gravitate towards Loglan--Lojban.

I define a loglang as one that can unambiguously encode any explicit predicate logic formula in a way that is no less concise than the way natlangs would express the formula (with much greater ambiguity and leaving much more to be glorked from context). The relevance of the concision requirement is firstly that without it, the gain in clarity is not necessarily worth the effort of greater verbosity; rather, the goal is to up the clarity-to-verbosity ratio. And secondly, designing a language that can unambiguously encode any explicit predicate logic formula is trivially easy; it's only the concision requirement that makes the challenge difficult (or maybe impossible). Not everybody defines their sought-for loglang by these criteria. For example, John Clifford and Martin Bays are very preoccupied with having a highly specified semantics for the loglang, which is something I'm rather unsympathetic to.

Just several hours ago I posted a short note on another critique of Lojban from the side semanticophils.

Considered *as a loglang (in my definition of that term)*, Lojban is a complete failure, though it must be borne in mind that it wasn't fundamentally designed to be a loglang; the loglang aspect is more part of its (undeserved) reputation than its essence. (I should clarify that, once the BPFK does its work, which basically involves Robin wielding the political muscle and Xorxes wielding the intellectual muscle, Lojban would succeed in being logically unambiguous. The failure is to meet the (never aimed-for) criterion of concision.) (I should also note that Lojban has been a success relative to the goals of the founders of Lojban, namely to create a public-domain stable "finished" version of Loglan around which a community of users can grow.)

I'm here (on this list) partly because I've been part of the community for over 20 years, and at certain times have been the most active participant, so I feel a sense of (always marginalized) belonging. But also I'm here because I think there's a chance of a genuine loglang coupled with a community of sponsors emerging from the Loglan--Lojban community. There might come a time when enough folk that think as I do have gravitated hither that some sort of critical mass is formed and work on an ergonomically usable loglang is begun.

It's easy to think of ways of drastically improving on the Lojban design.

 

For example, discard rafsi

 How would you distinguish between {latcribe} and {mlatu cribe} then? The latter is definitely not panda.

, make all gismu CCV -- becomes conciser and easier to learn in one go.

Yes, lowering signal-to-noise ratio even further ;)

Or discard almost all selmaho, default to Polish notation syntax,

Can you provide us with any draft of such language? 

and you have something much conciser, much more easy to learn, much more easy to parse. I suppose that even these changes are so drastic that they'd amount to discarding the current Loglan--Lojban entirely and starting over, but I think a complete redesign is anyway necessary because of the one fundamental design challenge of a loglang, which is the challenge of representing where two argument-places have the same value (e.g. in "John laughed and sneezed", where the argument-place of John(), of Laugh() and of Sneeze() have the same value): specifically, the challenge is to represent that in a concise and human-usable way (bearing in mind that a normal sentence might involve dozens of groups of argument-places that have the same value). You c
ould call this loglang "LoCCan3", but, unlike John Clifford's vision, it couldn't be achieved by incremental revisions to LoCCan2.

I can praise any improvements backward compatible with the current language. But any new loglangs not having a parser just don't exist to me.   They are just projects, not working loglangs.

--And.

[la gleki]

On Saturday, July 7, 2012 12:51:13 AM UTC+4, stevo wrote:

To return to the original question, I would like a new version of Loglan/Lojban that fixed the perceived problems associated with those two languages.

What are the problems perceived by you? 

I don't know what my solution would look like (well, I have a version, but it's only a relex of the gismu, so I don't normally count it). 

And the sooner the better.

Who can do that if not those interested in loccan3? :)

[MorphemeAddict]

On Fri, Jul 6, 2012 at 10:45 PM, la gleki <gleki.is...@gmail.com> wrote:

On Saturday, July 7, 2012 12:51:13 AM UTC+4, stevo wrote:

To return to the original question, I would like a new version of Loglan/Lojban that fixed the perceived problems associated with those two languages.

What are the problems perceived by you? 

I would redo the entire vocabulary, eliminate rafsi or at least regularize the means for lujvo creation, simplify the grammar a lot. RPN, mentioned in a recent post, appeals to me. I like the simple grammar of Rick Morneau's Latejami. 

Many of the issues of Lojban's faults are beyond me: scoping issues, variables, prenexes. I'd like it to be more like math notation. 

I don't know what my solution would look like (well, I have a version, but it's only a relex of the gismu, so I don't normally count it). 

And the sooner the better.

Who can do that if not those interested in loccan3? :)

I doubt anyone would do it if he wasn't interested in the result. And the defects of Lojban are best determined by fluent speakers. So until there is a community that can debate the issue in fluent Lojban, it probably shouldn't happen. 

stevo

[la gleki]

Untimely request from me (as it's bazi jbonunsla now).

Guys currently in San Mateo, please discuss la xorxes's proposals once again. Make connectives easier to use and learn until there we get  many more lojbanists. It would be too late to fix anything then.

[la .lindar.]

Guys currently in San Mateo, please discuss la xorxes's proposals once again. Make connectives easier to use and learn until there we get  many more lojbanists. It would be too late to fix anything then.

While it is, as of right now, ultimately the decision of Robin Powell, I will, as a member of the BPFK, will not approve the revision I think you're talking about (making jeks work the same place eks work) and will loudly voice my opinion against it. I think it's a horrible idea and removes the conciseness of the language as it stands. There's no reason to remove eks and I don't think it's that bloody difficult to learn all of the connectors.

If you mean something else, please let me know. 

[la .lindar.]

"I will, as a member of the BPFK, will not"

That feel when you post something super-serious and then notice a typo.

I rescind my argument to be made at a later time when I haven't been sleep-deprived for an entire month.

[Veijo Vilva]

On 7 July 2012 07:50, la .lindar. <lindar...@gmail.com> wrote:

Guys currently in San Mateo, please discuss la xorxes's proposals once again. Make connectives easier to use and learn until there we get  many more lojbanists. It would be too late to fix anything then.

While it is, as of right now, ultimately the decision of Robin Powell, I will, as a member of the BPFK, will not approve the revision I think you're talking about (making jeks work the same place eks work) and will loudly voice my opinion against it. I think it's a horrible idea and removes the conciseness of the language as it stands. There's no reason to remove eks and I don't think it's that bloody difficult to learn all of the connectors.

I had a look at the "mad" proposals, and in my opinion they don't seem mad at all and would make the language much more concise than the present form is. I'd make one more simplification, i.e., use only GI as a connective medial. The PEG version of the Lojban grammar is slightly more permissive than the old YACC version was and allows a few more KU's to be elided thus removing the YACC derived extra KU problem mentioned in the proposal.

With the additional GI change to the proposal, the PEG grammar can be modified to accept both usage versions without breaking any old texts which now pass the parser (all old text don't pass, BTW.) The minimum change affects only four rules in the BEG, and the resulting parser gives an identical parse for Alice compared to the one produced by my unmodified parser.

This kind of change would keep the underlying grammar identical (except for the ortogonalization of the tanru connectives), only some surface details would change. This would be a much smaller change than xorlo, which was rather a fundamental change and, e.g., for me much more difficult to stomach than these "mad" proposals, which are more akin to normal, fluid, living language evolution a streamlining but a very controlled one compared to the phenomena in natural language evolution. 

    veion

--

  web site: http://galactinus.net/vilva/

  on Google+: https://plus.google.com/106533767817816079660/posts

[la gleki]

This reply from Veijo says to me much more than all the previous stuff that has been discussed in this topic.

doi .lindar. I wasn't arguing for removing any stuff from the language.

I suggest only adopting alternative solutions preserving backward compatibility with all old texts (breaking it in extreme cases if-and-only-if rubbing out old incompatible texts is easy).

[la .lindar.]

*Regardless* of the arguments, I'm staunchly against it precisely for the fact that people will *use* it. Regardless of whether or not *I* have to use it, *other* people will, which means that *I* have to learn to read it. Therefore, it *does* affect me, even if I *do* choose to use the original sumti connectives. Therefore, I will always veto this idea every time forever.

That being said, I will gladly bring it to Robin's attention, who I presume will laugh and say, "Fuck no.", but very well may not.

I'll even see about getting video footage of the discussion.

[And Rosta]

la gleki, On 07/07/2012 03:33:

> On Saturday, July 7, 2012 12:45:26 AM UTC+4, And Rosta wrote:
> I define a loglang as one that can unambiguously encode any explicit
> predicate logic formula in a way that is no less concise than the way
> natlangs would express the formula (with much greater ambiguity and
> leaving much more to be glorked from context). The relevance of the
> concision requirement is firstly that without it, the gain in clarity
> is not necessarily worth the effort of greater verbosity; rather, the
> goal is to up the clarity-to-verbosity ratio. And secondly, designing
> a language that can unambiguously encode any explicit predicate logic
> formula is trivially easy; it's only the concision requirement that
> makes the challenge difficult (or maybe impossible). Not everybody
> defines their sought-for loglang by these criteria. For example, John
> Clifford and Martin Bays are very preoccupied with having a highly
> specified semantics for the loglang, which is something I'm rather
> unsympathetic to.
>
> Just several hours ago I posted a short note

> <https://www.facebook.com/photo.php?fbid=236029819851609&set=a.200050570116201.43269.100003337779349&type=1&theater&notif_t=photo_comment>

> on another critique of Lojban from the side semanticophils.

I've looked at that note, and I think it misunderstands what John Q is saying. The point in the intro is about how the basic lexicon covers semantic space, i.e. how you select your inventory of basic morphemes, whereas the point in the last chapter pertains to a kind of inventory of primitives for a metalanguage for defining meanings (i.e. a Wierzickan-type enterprise). He's talking about two different things. Incidentally, I disagree with the idea of a closed-set of primitives, as something philosophically untenable, tho an open set of primitives is something I'm in favour of.

> It's easy to think of ways of drastically improving on the Lojban
> design.
>
> For example, discard rafsi
>
> How would you distinguish between {latcribe} and {mlatu cribe} then?
> The latter is definitely not panda.

That question can't really be answered without imagining an alternative morphology. Suppose the parser worked strictly left-to-right with no lookahead, and we said that every V is word-final. Then if gismu were CCV, a form C1-[C2-C3-V] could be used to indicate that it was non-final in a compound, the C1 being functionally equivalent to {zei}. But more importantly, the number of cmavo should be shrunk to the minimum, and the length of cmavo and gismu should be inversely proportional to their frequency.

> , make all gismu CCV -- becomes conciser and easier to learn in one go.
>
> Yes, lowering signal-to-noise ratio even further ;)

Indeed. Concision is far more important than noise-resistance, and it is far easier to give a basically concise system an expanded noise-resistant version than to give a basically verbose noise-resistant system a concise form.

> Or discard almost all selmaho, default to Polish notation syntax,
>
> Can you provide us with any draft of such language?

It's not really worth the effort, since the feasibility of the system is pretty obvious: ordinary predicate logic is consistent with Polish and Reverse Polish notations.I would insist on something that can be parsed incrementally left-to-right with no lookahead, which keeps everything simple.

> and you have something much conciser, much more easy to learn, much more easy to parse. I suppose that even these changes are so drastic that they'd amount to discarding the current Loglan--Lojban entirely and starting over, but I think a complete redesign is anyway necessary because of the one fundamental design challenge of a loglang, which is the challenge of representing where two argument-places have the same value (e.g. in "John laughed and sneezed", where the argument-place of John(), of Laugh() and of Sneeze() have the same value): specifically, the challenge is to represent that in a concise and human-usable way (bearing in mind that a normal sentence might involve dozens of groups of argument-places that have the same value). You c
> ould call this loglang "LoCCan3", but, unlike John Clifford's vision, it couldn't be achieved by incremental revisions to LoCCan2.
>
> I can praise any improvements backward compatible with the current language. But any new loglangs not having a parser just don't exist to me. They are just projects, not working loglangs.

I don't know what counts as backward-compatibility. Xorxes's proposals probably strike a balance of worthwhileness and backward-compatibility. A "working parser" strikes me as an irrelevance: the parsing algorithm for an ergonomic loglang should be so simple that its parsability should be self-evident.

--And.

[la .lindar.]

Curious...

Why not just make it already?

Quit talking and just do it. >_>

[Jonathan Jones]

I would prefer we didn't have another split, myself. We have Loglan, Lojban, Gua/Spi, Ithkuil, and possibly other much less known derivatives already. Every time someone decides to start a new lojbau, everyone suffers. And regardless of what problems your chosen lojbau is, it isn't perfect. It never will be. Dividing our efforts just makes it so that the true goal of all these languages- to be /spoken/ by /people/- will never be accomplished.

The quest for perfection is a futile one. What we have with Lojban now is good. Granted, it could be better, but that will always be true. It was true of "LoCCan1", it's true of "LoCCan2", and it will be true of "LoCCan34234234234". Starting over from scratch isn't the solution. Yes, you may be able to make a new lojbau that doesn't have the problems you perceive in "LoCCanN-1", but by making it, you create a new divide.

If we want jbogugde to exist, if we want people to speak our language- whichever one we decide on- then what we need to do is not to make a new one whenever we see problems. We need to either find an acceptable solution /within/ our language, or we need to /deal with it/.

French is the third largest language on the internet. How many people do you think would bother to learn French if every region had their own, mutually incompatible dialects? Would English be nearly as pervasive as it is if British, Australian, South African, and U.S. English speakers couldn't understand each other?

To quote a rather famous saying, "Divided we fall, united we stand". I view LoCCan3, and any other split, as the worst possible thing that could happen to us as a whole.

--

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/-/w5Smfyps8F8J.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .aionys.

.i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o
(Come to the Dot Side! Luke, I am your father. :D )

[And Rosta]

John E Clifford, On 07/07/2012 02:08:

> I do think there can be incremental improvements within Lojban toward
> a viable spoken FOL, guaranteed accurate, and not so prolix as to be
> unusable (people do use German after all, when English is available
> -- and Chinese).

Yes, there could be incremental improvements, but you'd end up with something looking nothing like its evolutionary ancestor. And really it would be far easier to start from scratch than to try to get by incremental steps to a solution that is hard enough to attain even if you were to start from scratch.

I should clarify, that I'm not just thinking about how to make typical Lojban sentences conciser. Rather, I'm imagining a system in which there is no concision gain in filling a place with zo'e than with something explicit and not relying on glorking. Ideally, a system where the co-filled status of a group of co-filled argument places is shown by a more economical method than simply sticking the same variable in each place overtly.

--And.

[kozmikreis]

On 8 Jul 2012, at 20:31, Jonathan Jones wrote:

Would English be nearly as pervasive as it is if British, Australian, South African, and U.S. English speakers couldn't understand each other?

Without otherwise detracting from your very good post, I take it you haven't seen any Rab C. Nesbitt rants, e.g., http://www.youtube.com/watch?v=8k7VoFiagfs

I'm English and speak what you might refer to as British English, and used to watch that show with the subtitles on, even though that's from the country next door and also falls under your classification of British English :-)

kozmikreis

[Veijo Vilva]

On 8 July 2012 21:14, la .lindar. <lindar...@gmail.com> wrote:

*Regardless* of the arguments, I'm staunchly against it precisely for the fact that people will *use* it. Regardless of whether or not *I* have to use it, *other* people will, which means that *I* have to learn to read it. Therefore, it *does* affect me, even if I *do* choose to use the original sumti connectives. Therefore, I will always veto this idea every time forever.

That being said, I will gladly bring it to Robin's attention, who I presume will laugh and say, "Fuck no.", but very well may not.

I'm not proposing a change in the language, not yet, anyway. I'm using this as a case study to find out the *purely technical* problems this kind and magnitude of change would cause, especially at the level of my present parser framework.

Using a parser as the basis for various linguistic tools can simplify many tasks, e.g,, syntax sensitive re-coding. It turned out to be a trivial task to add an official-to-mad coder process to my parser, and adding a mad-to-official coder is just mechanical work now that the basis for re-coding is there. After a two-way re-coding mechanism is available, the parser can be used to ascertain that a supposedly one-to-one change doesn't break anything. The re-coding process doesn't appreciably affect the parsing time, even for Alice the increase is of the order of one second.

If we ever get so far that we are seriously considering moving on from the baseline, we need tools like this to study the effect of the proposed changes. I also think that before that stage it would be quite useful and wise to do various kinds of hypothetical case studies, which would help to chart the territory. It is well nigh impossible to say anything definite on the basis of a few hand-crafted examples. A proposed change may look good in theory but turn out to be a flop in practice, and vice versa. Pushing sections of the existing corpus through an automatic coder and looking at the result will tell a lot more about various aspects (intelligibility, learnability, aesthetics &c.) and perhaps help to overcome prejudices concerning a proposed change, both pro and con, that is.

  veion

[la gleki]

Indeed. And Rosta, please present something.

[la gleki]

On Sunday, July 8, 2012 11:31:30 PM UTC+4, aionys wrote:

I would prefer we didn't have another split, myself. We have Loglan, Lojban, Gua/Spi, Ithkuil, and possibly other much less known derivatives already. Every time someone decides to start a new lojbau, everyone suffers. And regardless of what problems your chosen lojbau is, it isn't perfect. It never will be. Dividing our efforts just makes it so that the true goal of all these languages- to be /spoken/ by /people/- will never be accomplished.

The quest for perfection is a futile one. What we have with Lojban now is good. Granted, it could be better, but that will always be true. It was true of "LoCCan1", it's true of "LoCCan2", and it will be true of "LoCCan34234234234". Starting over from scratch isn't the solution. Yes, you may be able to make a new lojbau that doesn't have the problems you perceive in "LoCCanN-1", but by making it, you create a new divide.

If we want jbogugde to exist, if we want people to speak our language- whichever one we decide on- then what we need to do is not to make a new one whenever we see problems. We need to either find an acceptable solution /within/ our language, or we need to /deal with it/.

French is the third largest language on the internet. How many people do you think would bother to learn French if every region had their own, mutually incompatible dialects? Would English be nearly as pervasive as it is if British, Australian, South African, and U.S. English speakers couldn't understand each other?

To quote a rather famous saying, "Divided we fall, united we stand". I view LoCCan3, and any other split, as the worst possible thing that could happen to us as a whole.

On Sun, Jul 8, 2012 at 12:44 PM, la .lindar. <lindar...@gmail.com> wrote:

Curious...

Why not just make it already?

Quit talking and just do it. >_>

--
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/-/w5Smfyps8F8J.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .aionys.

.i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o
(Come to the Dot Side! Luke, I am your father. :D )

pe'isai For me proposals like xorxes's proposal for connectives are acceptable.

pe'isai And Rosta's is not (mere relexing is even less acceptable). But I'll study it anyway if ey publishes it.

[MorphemeAddict]

Ithkuil is not a Loglan derivative, indeed it's not even a loglang, although it is an engelang. And Ithkuil was never meant to be spoken by anyone. It's a proof-of-concept project. 

For myself, if Lojban (or even Loglan) is 'good enough', then so is any natlang. I'd rather start from scratch, using knowledge gained from previous attempts, than continue learning or using a language that is merely 'good enough'. 

stevo

To view this discussion on the web visit https://groups.google.com/d/msg/lojban/-/qM7QZfsDSj0J.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[Jonathan Jones]

Well then, have fun with that. I'm sorry to see you go.

[MorphemeAddict]

On Mon, Jul 9, 2012 at 2:43 AM, Jonathan Jones <eye...@gmail.com> wrote:

Well then, have fun with that. I'm sorry to see you go.

I can do both: continue to learn from current flawed languages while working on an improved version. 

I have no plans to leave this list or the Lojban community. 

[la gleki]

On Sunday, July 8, 2012 10:32:36 PM UTC+4, And Rosta wrote:

la gleki, On 07/07/2012 03:33:
> On Saturday, July 7, 2012 12:45:26 AM UTC+4, And Rosta wrote:
> I define a loglang as one that can unambiguously encode any explicit
> predicate logic formula in a way that is no less concise than the way
> natlangs would express the formula (with much greater ambiguity and
> leaving much more to be glorked from context). The relevance of the
> concision requirement is firstly that without it, the gain in clarity
> is not necessarily worth the effort of greater verbosity; rather, the
> goal is to up the clarity-to-verbosity ratio. And secondly, designing
> a language that can unambiguously encode any explicit predicate logic
> formula is trivially easy; it's only the concision requirement that
> makes the challenge difficult (or maybe impossible). Not everybody
> defines their sought-for loglang by these criteria. For example, John
> Clifford and Martin Bays are very preoccupied with having a highly
> specified semantics for the loglang, which is something I'm rather
> unsympathetic to.
>
> Just several hours ago I posted a short note
> <https://www.facebook.com/photo.php?fbid=236029819851609&set=a.200050570116201.43269.100003337779349&type=1&theater&notif_t=photo_comment>
> on another critique of Lojban from the side semanticophils.

I've looked at that note, and I think it misunderstands what John Q is saying. The point in the intro is about how the basic lexicon covers semantic space, i.e. how you select your inventory of basic morphemes

It is. It says how you select root words. They all appear to be taken from English semantics etc.

, whereas the point in the last chapter pertains to a kind of inventory of primitives for a metalanguage for defining meanings (i.e. a Wierzickan-type enterprise).

Indeed, he wanted to rearrange semantic space using his new affixes not always having equivalents in most common languages. But he admits  that he fails to do that for everything. I can see that he has roots for "NECKTIE/CRAVATTE". But if so then whty criticising Lojban if you have the same?

It's nice that you are creating a new language. But why stretching the truth about your own child? Ithkuil doesn't resolve such issue and nobody is likely to make huge progress here.

Still we can argue about this in theory but practice shows that in most cases Ithkuil affixes correspond to Lojbanic words (not taking into account that Lojbanic predicates have arguments whereas Ithkuil's do not or the meaning of their derivatives is postulated which wipes out all charm).

The remaining part of Ithkuil is nevetherless worth studying. He accumulated features of many nice conlangs in his project.
So we should be friends with him as well (as will all the other thinkers). I respect John Quijada's work very much.

It's not fighting with him. Just defending Lojban.

[MorphemeAddict]

If LoCCan3 is backward compatible with Lojban, then it's still Lojban, and not really LoCCan3, although maybe LoCCan2.1. 

LoCCan3 will be different from Lojban. 

stevo

--

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/-/YJA_ZrdYxXsJ.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[la gleki]

On Tuesday, July 10, 2012 3:27:55 AM UTC+4, stevo wrote:

If LoCCan3 is backward compatible with Lojban, then it's still Lojban, and not really LoCCan3, although maybe LoCCan2.1. 

LoCCan3 will be different from Lojban. 

Indeed.We should use terms more carefully.

 

stevo

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

[And Rosta]

la gleki, On 09/07/2012 06:08:

Alas, Gleki, it is on my list of projects, but with relatively low priority on that list. Specifically, there are two relevant projects: one is an essay describing a possible solution to the core problem of loglangs (namely, representation of co-filled argument places); the other is an essay describing a modular approach to the creation of a logical language. The second is not stunningly original, but might serve to frame and focus any collaborative effort that ever emerges. As for the first, I'm not convinced the solution is processable by the human language faculty, and the problem may instead remain unsolved; I suppose publishing it might spur others to seek better solutions, but shortage of time for publishing one's projects is the bane of my life.

I could sit down and jot down in an email a sketch of something patently better as a loglang than Lojban, but the only worthwhile loglang is the one that cracks that fundamental problem of ergonomically representing co-filled argument places; without that, any other incremental improvement to Lojban has lost its appeal to me.

--And.

[.arpis.]

What the heck is a "co-filled argument place" and does it have anything to do with a categorical dual?

--
You received this message because you are subscribed to the Google Groups "lojban" group.

To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
mu'o mi'e .arpis.

[And Rosta]

It's true that the set of people attracted to one engelang probably largely overlaps the set of people attracted to other engelangs, and hence that a proliferation of engelangs dilutes interest in any single engelang, tho I don't see why that should be a problem.

Perhaps you agree with me that human society would be improved if it had access to a common loglang. In that case, a proliferation of different but all adequate loglangs would be unfortunate -- it would be better for there to be a monopoly of one common loglang. But currently no adequate loglang exists. To create one, I feel you'd have to encourage both plurality of competing (but unowned) candidates and one or more collaboratively created candidates -- in the hope of generating the best ideas and finding solutions to unsolved problems. If no adequate loglang existed but it was easy to make one, I expect I and others would have made one and published it, but it's not easy to find a way to unambiguously encode logical forms in an ergonomic way.

--And.

Jonathan Jones, On 08/07/2012 20:31:

> I would prefer we didn't have another split, myself. We have Loglan, Lojban, Gua/Spi, Ithkuil, and possibly other much less known derivatives already. Every time someone decides to start a new lojbau, everyone suffers. And regardless of what problems your chosen lojbau is, it isn't perfect. It never will be. Dividing our efforts just makes it so that the true goal of all these languages- to be /spoken/ by /people/- will never be accomplished.
>
> The quest for perfection is a futile one. What we have with Lojban now is good. Granted, it could be better, but that will always be true. It was true of "LoCCan1", it's true of "LoCCan2", and it will be true of "LoCCan34234234234". Starting over from scratch isn't the solution. Yes, you may be able to make a new lojbau that doesn't have the problems you perceive in "LoCCanN-1", but by making it, you create a new divide.
>
> If we want jbogugde to exist, if we want people to speak our language- whichever one we decide on- then what we need to do is not to make a new one whenever we see problems. We need to either find an acceptable solution /within/ our language, or we need to /deal with it/.
>
> French is the third largest language on the internet. How many people do you think would bother to learn French if every region had their own, mutually incompatible dialects? Would English be nearly as pervasive as it is if British, Australian, South African, and U.S. English speakers couldn't understand each other?
>
> To quote a rather famous saying, "Divided we fall, united we stand". I view LoCCan3, and any other split, as the worst possible thing that could happen to us as a whole.
>

> On Sun, Jul 8, 2012 at 12:44 PM, la .lindar. <lindar...@gmail.com <mailto:lindar...@gmail.com>> wrote:
>
> Curious...
>
> Why not just make it already?
> Quit talking and just do it. >_>
>
> --
> 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/-/w5Smfyps8F8J.
>

> To post to this group, send email to loj...@googlegroups.com <mailto:loj...@googlegroups.com>.
> To unsubscribe from this group, send email to lojban+un...@googlegroups.com <mailto:lojban%2Bunsu...@googlegroups.com>.

> For more options, visit this group at http://groups.google.com/group/lojban?hl=en.
>
>
>
>
> --
> mu'o mi'e .aionys.
>
> .i.e'ucai ko cmima lo pilno be denpa bu .i doi.luk. mi patfu do zo'o
> (Come to the Dot Side! Luke, I am your father. :D )
>

> --
> You received this message because you are subscribed to the Google Groups "lojban" group.

[And Rosta]

Co-filled argument places are argument-places that have the same value, e.g. in "Fx & Gx", the sole argument places of F and of G are co-filled. Lojban avoids the verbosity of filling every place by giving speakers the option of not encoding it (and implicitly or explicitly filling the place with zo'e). I googled "categorical dual", but couldn't see any relevance to this discussion.

.arpis., On 10/07/2012 20:14:

> What the heck is a "co-filled argument place" and does it have anything to do with a categorical dual?
>

> On Tue, Jul 10, 2012 at 3:02 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:
>
> la gleki, On 09/07/2012 06:08:
>
>
>
> On Sunday, July 8, 2012 10:44:50 PM UTC+4, la .lindar. wrote:
>
> Curious...
>
> Why not just make it already?
> Quit talking and just do it. >_>
>
>
> Indeed. And Rosta, please present something.
>
>
> Alas, Gleki, it is on my list of projects, but with relatively low priority on that list. Specifically, there are two relevant projects: one is an essay describing a possible solution to the core problem of loglangs (namely, representation of co-filled argument places); the other is an essay describing a modular approach to the creation of a logical language. The second is not stunningly original, but might serve to frame and focus any collaborative effort that ever emerges. As for the first, I'm not convinced the solution is processable by the human language faculty, and the problem may instead remain unsolved; I suppose publishing it might spur others to seek better solutions, but shortage of time for publishing one's projects is the bane of my life.
>
> I could sit down and jot down in an email a sketch of something patently better as a loglang than Lojban, but the only worthwhile loglang is the one that cracks that fundamental problem of ergonomically representing co-filled argument places; without that, any other incremental improvement to Lojban has lost its appeal to me.
>
> --And.
>
>
> --
> You received this message because you are subscribed to the Google Groups "lojban" group.

> To post to this group, send email to loj...@googlegroups.com <mailto:loj...@googlegroups.com>.
> To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsu...@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.

>
>
>
>
> --
> mu'o mi'e .arpis.
>

> --
> You received this message because you are subscribed to the Google Groups "lojban" group.
> To post to this group, send email to loj...@googlegroups.com.

> To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[.arpis.]

It's not relevant to the discussion, except in that the prefix "co-" is also used to indicate it.

On Tue, Jul 10, 2012 at 3:26 PM, And Rosta <and....@gmail.com> wrote:

Co-filled argument places are argument-places that have the same value, e.g. in "Fx & Gx", the sole argument places of F and of G are co-filled. Lojban avoids the verbosity of filling every place by giving speakers the option of not encoding it (and implicitly or explicitly filling the place with zo'e). I googled "categorical dual", but couldn't see any relevance to this discussion.

.arpis., On 10/07/2012 20:14:

What the heck is a "co-filled argument place" and does it have anything to do with a categorical dual?

On Tue, Jul 10, 2012 at 3:02 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:

    la gleki, On 09/07/2012 06:08:



        On Sunday, July 8, 2012 10:44:50 PM UTC+4, la .lindar. wrote:

             Curious...

             Why not just make it already?
             Quit talking and just do it. >_>


        Indeed. And Rosta, please present something.


    Alas, Gleki, it is on my list of projects, but with relatively low priority on that list. Specifically, there are two relevant projects: one is an essay describing a possible solution to the core problem of loglangs (namely, representation of co-filled argument places); the other is an essay describing a modular approach to the creation of a logical language. The second is not stunningly original, but might serve to frame and focus any collaborative effort that ever emerges. As for the first, I'm not convinced the solution is processable by the human language faculty, and the problem may instead remain unsolved; I suppose publishing it might spur others to seek better solutions, but shortage of time for publishing one's projects is the bane of my life.

    I could sit down and jot down in an email a sketch of something patently better as a loglang than Lojban, but the only worthwhile loglang is the one that cracks that fundamental problem of ergonomically representing co-filled argument places; without that, any other incremental improvement to Lojban has lost its appeal to me.

    --And.


    --
    You received this message because you are subscribed to the Google Groups "lojban" group.

    To post to this group, send email to loj...@googlegroups.com <mailto:lojban@googlegroups.com>.
    To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsubscribe@googlegroups.com>.

    For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.

--
mu'o mi'e .arpis.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[la gleki]

Let's name 

Loglan = LoCCan 1.0

Lojban = LoCCan 2.0

Lojban after xorlo reform = LoCCan 2.1

Preliminary analysis of this topic.

I can see several proposals on LoCCans including LoCCan > 2.1 and Loccan sibling projects.

Let's range them from backward-incompatible to tiny Lojban improvements.

(I won't analyse every proposal, though)

1. Backward-incompatible And Rosta's project of CCV-gismu equal to rafsi and CCVrCCV lujvo where "r" is a buffer consonant. This lowers signal-to-noise ratio but makes learning rafsi=gismu much easier (no separate forms for gismu/rafsi). This can possibly remove the need in many modal tags that are actually duplicates and compressed versions of gismu

2. Backward-incompatible stevo's proposal of syntax that is always left-grouping. This can also increase the simplicity of the language

3. Backward-compatible la gleki's idea of rafybri packing bridi into lujvo-like structure retaing internal predicate relations as opposed to ordinary lujvo (by adding 4 new rafsi for x2...x5 place tags and extensively using {-jve-} for x1 tag). https://groups.google.com/forum/#!topic/lojban/64L-yY8ete8/discussion

4. Backward-compatible xorxes's proposal on connectives that suggest learning a smaller set of connectives.

5. Backward-compatible massive introduiction of experimental cmavo by some lojbanists. This might improve language flexibility but make learning harder. (Compare Loglan=Loccan 1.0) that had around 200 cmavo only.

Does Loccan3 have future?

Let's imagine that And Rosta, stevo and la gleki merged their efforts to produce a new Loccan. Let's imagine that they succeeded in rewriting the dictionary and the CLL. What next?

The answer is very short. The project will become viable if they have enough resources to adapt the whole lojban corpus (including lojban.org wiki) and grow the number of students to ~100. Then the schism will be successful and I will for sure leave Lojbanistan.

Needless to say that this goal is not likely to be reached in the nearest future. And I won't accept any half-done work. Still it would be nice to read it (just like with Ithkuil).

Comment on rafybri.

I have to say a word of rafybri and And Rosta's proposals.

We can start reading a very old (but still valid) paper by Nick Nicholas [http://www.lojban.org/files/papers/nsn_semantics_paper] where he slightly critisizes selecting sumti places for lujvo.

For me such play with sumti places is may be the most terrible drawback of lojban. And therefore I'm for paying more attention to Deep Gismu structure. I don't like {posydji}  but like {ko'a djica lo nu ko'e ponse ko'i}.

And Rosta's suggests relexing gismu. Still lujvo in eir language will have no internal predicate structure.

Rafybri compress some bridi preserving sumti places between two or more gismu. They are equivalent in meaning to some lujvo but donot require learning them by rot.

However, ordinary lujvo retain broken vague ambiguous internal structure of tanru with no places.

I don't think And Rosta's CCV suggestion is much better than rafybri (rafybri can be used immediately as they add new rules but donot destroy any old rules). But let's wait until ey presents something.

Therefore my choice within the baseline is

* no lujvo if you can use gismu

* for complex concepts like computer terminology, names of plants and animals use lujvo and fu'ivla (you'll have to memorise them by rot anyway)

On Monday, July 2, 2012 10:17:57 AM UTC+4, la gleki wrote:

Several recent messages mentioned the need for LoCCan3.

I wonder is there really any demand for it?

lojban.org wiki mentions nothing special.

1. Fewer cmavo (but you are free to use fewer cmavo in current lojban)

2. There should be new cmavo for individuals, sets and masses

3. connectives

4. anaphoric pronouns

(sorry, I didn't understand a word in #2,3,4, can you explain it to me in plain language?).

5. gismu with another number of sumti (but you are free not to use some sumti, to use sumtcita etc.)

Anyway, even if so is there any need to break existing language?

[MorphemeAddict]

On Wed, Jul 11, 2012 at 3:41 AM, la gleki <gleki.is...@gmail.com> wrote:

Let's name 

Loglan = LoCCan 1.0

Lojban = LoCCan 2.0

Lojban after xorlo reform = LoCCan 2.1

Preliminary analysis of this topic.

I can see several proposals on LoCCans including LoCCan > 2.1 and Loccan sibling projects.

Let's range them from backward-incompatible to tiny Lojban improvements.

(I won't analyse every proposal, though)

1. Backward-incompatible And Rosta's project of CCV-gismu equal to rafsi and CCVrCCV lujvo where "r" is a buffer consonant. This lowers signal-to-noise ratio but makes learning rafsi=gismu much easier (no separate forms for gismu/rafsi). This can possibly remove the need in many modal tags that are actually duplicates and compressed versions of gismu

2. Backward-incompatible stevo's proposal of syntax that is always left-grouping. This can also increase the simplicity of the language

I didn't make such a proposal. I only mentioned that I like RPN. 

There are at least two different areas of improvement for Lojban: vocabulary and grammar. The vocabulary is essentially irrelevent. Any sufficiently concise, flexible, rigorous, and self-segregating (if that's a worthwhile feature) will do. The grammar is the important part for me, and I'm not sufficiently knowledgeable of grammar and logic to work on this. Distinguishing proposals by which area is affected seems a useful thing to do. 

stevo

[And Rosta]

la gleki, On 11/07/2012 08:41:

> Let's name
> Loglan = LoCCan 1.0
> Lojban = LoCCan 2.0
> Lojban after xorlo reform = LoCCan 2.1

As I understand it, Lojban was more of a fork from Loglan than an improvement of it -- essentially a Loglan relex with some other subsequent mostly gratuitous changes.

Nevertheless, your terminology is convenient.

> 1. Backward-incompatible And Rosta's project of CCV-gismu equal to
> rafsi and CCVrCCV lujvo where "r" is a buffer consonant.

[I had in mind this "r" being any consonant, not just /r/.]

This lowers
> signal-to-noise ratio but makes learning rafsi=gismu much easier (no
> separate forms for gismu/rafsi). This can possibly remove the need in
> many modal tags that are actually duplicates and compressed versions
> of gismu

I have no such project. The CCV thing was just an idea tossed out, as one of the many easy ways of improving on Lojban.

If I was asked for advice on LoCCan3, it'd be this, in the first instance:

Discard the LoCCan2 syntax, then start with predicate logic, and enrich it only with what predicate logic can't express or accommodate. Insist on the syntax being incrementally parsable with no lookahead, where parsability means recovering the logical form, not merely assigning some meaningless structure to surface phonology, as in the current so-called parser.

Apply some sort of Huffman-encoding type scheme to at least morphemes (possibly to morpheme strings). Possibly temper this by the desirability of having some sort of phonosemantic patterning among morphemes, for mnemonic purposes.

That's not be the end of my advice, but it'd be the key bits.

HOWEVER, I think that a LoCCan3 that did that would still not be good enough, and I don't see much point in investing a lot of effort into creating a language whose design is miles better than Lojban's but is still not fit for purpose. (I suppose that if future research were to show that the fundamental loglang problem is insoluble, then one would after all want the best possible LoCCan version, as the language least unfit for purpose.) To apprehend the fundamental loglang problem, imagine Lojban without {zo'e}, and then try to think how it could be redesigned to avoid being impossibly longwinded and impossibly taxing on the memory of (especially) the hearer/reader.

> And Rosta's suggests relexing gismu. Still lujvo in eir language will
> have no internal predicate structure.

Quite so. Since simplex brivla (gismu) would already have maximally short forms, complex brivla (lujvo) would be necessary only when the forms were not semantically compositional, i.e. when the meaning of the whole is not completely predictable from the meaning of the parts. The morphological translucence (semicompositionality) of lujvo would serve a merely mnemonic purpose.

> Rafybri compress some bridi preserving sumti places between two or
> more gismu. They are equivalent in meaning to some lujvo but donot
> require learning them by rot. However, ordinary lujvo retain broken
> vague ambiguous internal structure of tanru with no places. I don't
> think And Rosta's CCV suggestion is much better than rafybri (rafybri
> can be used immediately as they add new rules but donot destroy any
> old rules). But let's wait until ey presents something.

For the reasons given above, rafybri would be redundant in a well-designed loglan. Or, to put it a different way, a well designed loglan would use something akin to rafybri as its basic device.

--And.

[Gleki Arxokuna]

On Wednesday, July 11, 2012 10:36:56 PM UTC+4, And Rosta wrote:

la gleki, On 11/07/2012 08:41:
> Let's name
> Loglan = LoCCan 1.0
> Lojban = LoCCan 2.0
> Lojban after xorlo reform = LoCCan 2.1

As I understand it, Lojban was more of a fork from Loglan than an improvement of it -- essentially a Loglan relex with some other subsequent mostly gratuitous changes.

Nevertheless, your terminology is convenient.

Let's make it more clear

Loglan = LoCCan v. 1.0 - 1.9

Lojban = LoCCan v. 2.0 - 2.9

Lojban after xorlo reform = LoCCan v. 2.1 

So changing the first number loses compatibility.

> 1. Backward-incompatible And Rosta's project of CCV-gismu equal to
> rafsi and CCVrCCV lujvo where "r" is a buffer consonant.

[I had in mind this "r" being any consonant, not just /r/.]

yes, let's use your "C1" symbol then.

This lowers
> signal-to-noise ratio but makes learning rafsi=gismu much easier (no
> separate forms for gismu/rafsi). This can possibly remove the need in
> many modal tags that are actually duplicates and compressed versions
> of gismu

I have no such project. The CCV thing was just an idea tossed out, as one of the many easy ways of improving on Lojban.

Sorry, stevo and And Rosta. I should have removed your names from the preliminary analysis.

If I was asked for advice on LoCCan3, it'd be this, in the first instance:

Discard the LoCCan2 syntax, then start with predicate logic, and enrich it only with what predicate logic can't express or accommodate. Insist on the syntax being incrementally parsable with no lookahead, where parsability means recovering the logical form, not merely assigning some meaningless structure to surface phonology, as in the current so-called parser.

Apply some sort of Huffman-encoding type scheme to at least morphemes (possibly to morpheme strings). Possibly temper this by the desirability of having some sort of phonosemantic patterning among morphemes, for mnemonic purposes.

That's not be the end of my advice, but it'd be the key bits.

HOWEVER, I think that a LoCCan3 that did that would still not be good enough, and I don't see much point in investing a lot of effort into creating a language whose design is miles better than Lojban's but is still not fit for purpose. (I suppose that if future research were to show that the fundamental loglang problem is insoluble, then one would after all want the best possible LoCCan version, as the language least unfit for purpose.)  To apprehend the fundamental loglang problem, imagine Lojban without {zo'e}, and then try to think how it could be redesigned to avoid being impossibly longwinded and impossibly taxing on the memory of (especially) the hearer/reader.

No clue. Either you memorise FA in Lojban or you memorise prepositions for each verb in natlang. pe'i, the lojbanic solution is better.

> And Rosta's suggests relexing gismu. Still lujvo in eir language will
> have no internal predicate structure.

Quite so. Since simplex brivla (gismu) would already have maximally short forms, complex brivla (lujvo) would be necessary only when the forms were not semantically compositional, i.e. when the meaning of the whole is not completely predictable from the meaning of the parts. The morphological translucence (semicompositionality) of lujvo would serve a merely mnemonic purpose.

> Rafybri compress some bridi preserving sumti places between two or
> more gismu. They are equivalent in meaning to some lujvo but donot
> require learning them by rot. However, ordinary lujvo retain broken
> vague ambiguous internal structure of tanru with no places. I don't
> think And Rosta's CCV suggestion is much better than rafybri (rafybri
> can be used immediately as they add new rules but donot destroy any
> old rules). But let's wait until ey presents something.

For the reasons given above, rafybri would be redundant in a well-designed loglan. Or, to put it a different way, a well designed loglan would use something akin to rafybri as its basic device. 

Better to say in Loccan 2.0-2.9=Lojban then to move to Loccan >=3.0 

 

--And.

[MorphemeAddict]

On Thu, Jul 12, 2012 at 12:22 AM, Gleki Arxokuna <gleki.is...@gmail.com> wrote:

...

 

For the reasons given above, rafybri would be redundant in a well-designed loglan. Or, to put it a different way, a well designed loglan would use something akin to rafybri as its basic device. 

Better to say in Loccan 2.0-2.9=Lojban then to move to Loccan >=3.0 

 

hunh? Maybe "stay"? 

I want LoCCan 10 or 100 or higher. 

stevo 

[Gleki Arxokuna]

On Thursday, July 12, 2012 10:13:12 AM UTC+4, stevo wrote:

On Thu, Jul 12, 2012 at 12:22 AM, Gleki Arxokuna <gleki.is...@gmail.com> wrote:

...

 

For the reasons given above, rafybri would be redundant in a well-designed loglan. Or, to put it a different way, a well designed loglan would use something akin to rafybri as its basic device. 

Better to stay in Loccan 2.0-2.9=Lojban then to move to Loccan >=3.0 

 

hunh? Maybe "stay"? 

.u'u

yes, "stay" 

I want LoCCan 10 or 100 or higher. 

I want it too. Do you have one?

stevo 

[John E Clifford]

As far as I can figure from the limited information, &'s language differs from Logjam in two significant respects.

1. Instead of a predicate with various arguments dripping from it, the core utterance is an argument (topic, say) with dangling predicates (comments -- not the standard usage quite but Logjam is not famous for following precedents in terminology). This is a feasible structure, easily realized in two (and simply in three) dimensions, without anaphora.  The case of existential graphs and general topological considerations, however, suggest that anaphora will be needed in one-dimensional speech.  The usual problems with that are simplified by the canonical location of topics.  Multiple topics increase the complexity of this but not its basic simplicity.  Comments come and go (naturally) while topics run on and on (and so are always available for connection).

2.  Comments have no inherent places, which need to be filled implicitly when not explicitly, but have only those which are explicitly filled.  This means, apparently, that the nature of the connection of a comment to its topic has to be specified in (almost) every case, an added nuisance in speech but probably a simplification in learning (and possible a reduction in the need for compounds, many of which are just to add a place to an existing predicate or rearrange those places).  The bareness of comments means that comment words can be raised to topics directly to do business as properties or events, without a lot of extra detail. 

These points are too sketchy to give any notion of the relative size, ease or clarity of an &lang as here conceived, but at least it looks feasible so far.

---

[And Rosta]

Let me try harder to explain:


Take a variety of predicate logic consisting of predicates, quantifiers and variables. In normal predicate logic notation, if a given variable is an argument of more than one predicate, it gets repeated. And every bound variable is notated at least twice, once where it is shown bound by quantifier and once where it is argument of a predicate. But this is one and the same variable; the repetition is a mere notational device necessary to linearize the string.

If the notation could be two dimensional, then you wouldn't need to write variables at all. For simplicity's sake, I'll describe a notation for only predicates and variables:
Use a 2 dimensional grid, infinite in both dimensions.
Each 'row' corresponds to a variable.
Each 'column' corresponds to a predicate.
Predicates are notated by sets of symbols, one symbol for each argument place. Each argument place symbol is placed on the appropriate row for the variable that fills the argument place.

That's the basic data structure for predicate--argument structure. A 2-dimensional notation can notate it without redundancy. But spoken language is 1-dimensional. Is there a way of linearizing predicate-argument structure ergonomically, in such a way that it is not so verbose or so taxing on the memory that the advantages of its logical explicitness and unambiguousness are not outweighed?

--And.

John E Clifford, On 12/07/2012 17:17:

> **

>
> --
> You received this message because you are subscribed to the Google Groups "lojban" group.
> To post to this group, send email to loj...@googlegroups.com.

> To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[kozmikreis]

The 1-dimensional constraint of speech is a big one in terms of serializing anything significant. How about consider exploiting more than one 1-dimensional stream to slightly alleviate the issue, perhaps conveyed through semaphore or dance :-)

kozmikreis

[.arpis.]

The common way (speaking as a computer scientist) of avoiding variable repetition (and variable naming issues) in formal methods is to use De Bruijn indices (https://en.wikipedia.org/wiki/De_Bruijn_index), but this fails the requirement of fitting in human memory.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[MorphemeAddict]

Sadly, no. But the fastest way I know to get one is to produce and use as many versions as possible, figure out the benefits and flaws, and then create a new version based on that experience. "Good enough" isn't good enough. 

stevo

stevo 

--
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/-/aaZILIPEY2oJ.

To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[And Rosta]

.arpis., On 12/07/2012 23:09:

> The common way (speaking as a computer scientist) of avoiding variable repetition (and variable naming issues) in formal methods is to use De Bruijn indices (https://en.wikipedia.org/wiki/De_Bruijn_index), but this fails the requirement of fitting in human memory.

Can you give an example of how it would work if applied to a predicate--argument structure? I can't follow the wikipedia article enough to see how it would work (-- setting aside the memory limitation problem you mention).

> On Thu, Jul 12, 2012 at 2:31 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:
>
> Let me try harder to explain:
>
>
> Take a variety of predicate logic consisting of predicates, quantifiers and variables. In normal predicate logic notation, if a given variable is an argument of more than one predicate, it gets repeated. And every bound variable is notated at least twice, once where it is shown bound by quantifier and once where it is argument of a predicate. But this is one and the same variable; the repetition is a mere notational device necessary to linearize the string.
>
> If the notation could be two dimensional, then you wouldn't need to write variables at all. For simplicity's sake, I'll describe a notation for only predicates and variables:
> Use a 2 dimensional grid, infinite in both dimensions.
> Each 'row' corresponds to a variable.
> Each 'column' corresponds to a predicate.
> Predicates are notated by sets of symbols, one symbol for each argument place. Each argument place symbol is placed on the appropriate row for the variable that fills the argument place.
>
> That's the basic data structure for predicate--argument structure. A 2-dimensional notation can notate it without redundancy. But spoken language is 1-dimensional. Is there a way of linearizing predicate-argument structure ergonomically, in such a way that it is not so verbose or so taxing on the memory that the advantages of its logical explicitness and unambiguousness are not outweighed?
>
> --And.
>
> John E Clifford, On 12/07/2012 17:17:
>
> As far as I can figure from the limited information, &'s language differs from Logjam in two significant respects.
> 1. Instead of a predicate with various arguments dripping from it, the core utterance is an argument (topic, say) with dangling predicates (comments -- not the standard usage quite but Logjam is not famous for following precedents in terminology). This is a feasible structure, easily realized in two (and simply in three) dimensions, without anaphora. The case of existential graphs and general topological considerations, however, suggest that anaphora will be needed in one-dimensional speech. The usual problems with that are simplified by the canonical location of topics. Multiple topics increase the complexity of this but not its basic simplicity. Comments come and go (naturally) while topics run on and on (and so are always available for connection).
> 2. Comments have no inherent places, which need to be filled implicitly when not explicitly, but have only those which are explicitly filled. This means, apparently, that the nature of the connection of a comment to its topic has to be specified in (almost) every case, an added nuisance in speech but probably a simplification in learning (and possible a reduction in the need for compounds, many of which are just to add a place to an existing predicate or rearrange those places). The bareness of comments means that comment words can be raised to topics directly to do business as properties or events, without a lot of extra detail.
> These points are too sketchy to give any notion of the relative size, ease or clarity of an &lang as here conceived, but at least it looks feasible so far.
> **
>
> --
> You received this message because you are subscribed to the Google Groups "lojban" group.

> To post to this group, send email to loj...@googlegroups.com <mailto:loj...@googlegroups.com>.
> To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsu...@googlegroups.com>.

> For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.
>
>

> --
> You received this message because you are subscribed to the Google Groups "lojban" group.

> To post to this group, send email to loj...@googlegroups.com <mailto:loj...@googlegroups.com>.
> To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsu...@googlegroups.com>.

> For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.
>
>
>
>

> --
> mu'o mi'e .arpis.
>

> --
> You received this message because you are subscribed to the Google Groups "lojban" group.
> To post to this group, send email to loj...@googlegroups.com.

> To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[.arpis.]

I'm not sure I understand the predicate-argument structure well enough to do so. Could you give an example of how it would look with normal variables and explain the meaning of the example?

On Thu, Jul 12, 2012 at 6:44 PM, And Rosta <and....@gmail.com> wrote:

.arpis., On 12/07/2012 23:09:

The common way (speaking as a computer scientist) of avoiding variable repetition (and variable naming issues) in formal methods is to use De Bruijn indices (https://en.wikipedia.org/wiki/De_Bruijn_index), but this fails the requirement of fitting in human memory.

Can you give an example of how it would work if applied to a predicate--argument structure? I can't follow the wikipedia article enough to see how it would work (-- setting aside the memory limitation problem you mention).

On Thu, Jul 12, 2012 at 2:31 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:

    Let me try harder to explain:


    Take a variety of predicate logic consisting of predicates, quantifiers and variables. In normal predicate logic notation, if a given variable is an argument of more than one predicate, it gets repeated. And every bound variable is notated at least twice, once where it is shown bound by quantifier and once where it is argument of a predicate. But this is one and the same variable; the repetition is a mere notational device necessary to linearize the string.

    If the notation could be two dimensional, then you wouldn't need to write variables at all. For simplicity's sake, I'll describe a notation for only predicates and variables:
    Use a 2 dimensional grid, infinite in both dimensions.
    Each 'row' corresponds to a variable.
    Each 'column' corresponds to a predicate.
    Predicates are notated by sets of symbols, one symbol for each argument place. Each argument place symbol is placed on the appropriate row for the variable that fills the argument place.

    That's the basic data structure for predicate--argument structure. A 2-dimensional notation can notate it without redundancy. But spoken language is 1-dimensional. Is there a way of linearizing predicate-argument structure ergonomically, in such a way that it is not so verbose or so taxing on the memory that the advantages of its logical explicitness and unambiguousness are not outweighed?

    --And.

    John E Clifford, On 12/07/2012 17:17:

        As far as I can figure from the limited information, &'s language differs from Logjam in two significant respects.
        1. Instead of a predicate with various arguments dripping from it, the core utterance is an argument (topic, say) with dangling predicates (comments -- not the standard usage quite but Logjam is not famous for following precedents in terminology). This is a feasible structure, easily realized in two (and simply in three) dimensions, without anaphora. The case of existential graphs and general topological considerations, however, suggest that anaphora will be needed in one-dimensional speech. The usual problems with that are simplified by the canonical location of topics. Multiple topics increase the complexity of this but not its basic simplicity. Comments come and go (naturally) while topics run on and on (and so are always available for connection).
        2. Comments have no inherent places, which need to be filled implicitly when not explicitly, but have only those which are explicitly filled. This means, apparently, that the nature of the connection of a comment to its topic has to be specified in (almost) every case, an added nuisance in speech but probably a simplification in learning (and possible a reduction in the need for compounds, many of which are just to add a place to an existing predicate or rearrange those places). The bareness of comments means that comment words can be raised to topics directly to do business as properties or events, without a lot of extra detail.
        These points are too sketchy to give any notion of the relative size, ease or clarity of an &lang as here conceived, but at least it looks feasible so far.
        **

        --
        You received this message because you are subscribed to the Google Groups "lojban" group.

        To post to this group, send email to loj...@googlegroups.com <mailto:lojban@googlegroups.com>.
        To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsubscribe@googlegroups.com>.

        For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.

    --
    You received this message because you are subscribed to the Google Groups "lojban" group.

    To post to this group, send email to loj...@googlegroups.com <mailto:lojban@googlegroups.com>.
    To unsubscribe from this group, send email to lojban+unsubscribe@ googlegroups.com <mailto:lojban%2Bunsubscribe@googlegroups.com>.

    For more options, visit this group at http://groups.google.com/ group/lojban?hl=en <http://groups.google.com/group/lojban?hl=en>.

--
mu'o mi'e .arpis.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.

To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Gleki Arxokuna]

On Wednesday, July 11, 2012 10:36:56 PM UTC+4, And Rosta wrote:

la gleki, On 11/07/2012 08:41:
> Let's name
> Loglan = LoCCan 1.0
> Lojban = LoCCan 2.0
> Lojban after xorlo reform = LoCCan 2.1

As I understand it, Lojban was more of a fork from Loglan than an improvement of it -- essentially a Loglan relex with some other subsequent mostly gratuitous changes.

Nevertheless, your terminology is convenient.

> 1. Backward-incompatible And Rosta's project of CCV-gismu equal to
> rafsi and CCVrCCV lujvo where "r" is a buffer consonant.

[I had in mind this "r" being any consonant, not just /r/.]

This lowers
> signal-to-noise ratio but makes learning rafsi=gismu much easier (no
> separate forms for gismu/rafsi). This can possibly remove the need in
> many modal tags that are actually duplicates and compressed versions
> of gismu

I have no such project. The CCV thing was just an idea tossed out, as one of the many easy ways of improving on Lojban.

If I was asked for advice on LoCCan3, it'd be this, in the first instance:

 

Discard the LoCCan2 syntax, then start with predicate logic, and enrich it only with what predicate logic can't express or accommodate. Insist on the syntax being incrementally parsable with no lookahead, where parsability means recovering the logical form, not merely assigning some meaningless structure to surface phonology, as in the current so-called parser.

But what can stop us from using existing predicativeness of the current Lojban? If you don't like cmavo don't use them if you can. It's you speech style. It's not a separate language.

[And Rosta]

.arpis., On 13/07/2012 00:59:

> I'm not sure I understand the predicate-argument structure well
> enough to do so. Could you give an example of how it would look with
> normal variables and explain the meaning of the example?

An example (without wanting to be distracted by irrelevant details):

"Da djuno lo du'u de prami da gi'e de nelci da"
djuno(da, &(prami(de, da), nelci(de, da)))

Task 1: notate this (linearly) so that "da" and "de" each appear only once.

And then:

Task 2: Improve the system so that speakers don't have to hold in memory the arbitrary correspondence between variable & phonological form.

Will De Bruijn indices deal with Task 1? If they do, I'd be thrilled to have learnt summat new.

--And.

>
> On Thu, Jul 12, 2012 at 6:44 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:
>
> .arpis., On 12/07/2012 23:09:
>

> The common way (speaking as a computer scientist) of avoiding variable repetition (and variable naming issues) in formal methods is to use De Bruijn indices (https://en.wikipedia.org/ wiki/De_Bruijn_index <https://en.wikipedia.org/wiki/De_Bruijn_index>), but this fails the requirement of fitting in human memory.

>
>
> Can you give an example of how it would work if applied to a predicate--argument structure? I can't follow the wikipedia article enough to see how it would work (-- setting aside the memory limitation problem you mention).
>

[.arpis.]

On Fri, Jul 13, 2012 at 10:31 AM, And Rosta <and....@gmail.com> wrote:

.arpis., On 13/07/2012 00:59:

I'm not sure I understand the predicate-argument structure well
enough to do so. Could you give an example of how it would look with
normal variables and explain the meaning of the example?

An example (without wanting to be distracted by irrelevant details):

"Da djuno lo du'u de prami da gi'e de nelci da"
djuno(da, &(prami(de, da), nelci(de, da)))

Task 1: notate this (linearly) so that "da" and "de" each appear only once.

And then:

Task 2: Improve the system so that speakers don't have to hold in memory the arbitrary correspondence between variable & phonological form.

Will De Bruijn indices deal with Task 1? If they do, I'd be thrilled to have learnt summat new.

Ah... No. De Bruijn indices do nothing about factoring out common use sites. You might want to look into the SKI (or SK) calculus; it is capable of expressing everything that the lambda calculus is.

What you really want is to define a predicate out of djuno, du'u, prami, and nelci that has the right meaning and never use "da" or "de" at all, because if they appear only once and in obvious positions, they are superfluous.

Here's how I would go about deriving such a predicate, in case it helps:

Recognize that \ko'a. \ko'e. gi'e (prami ko'a ko'e) (nelci ko'a ko'e) is a useful abstraction
This abstraction can be generalized to
\conn. \b1. \b2. \ko'a. \ko'e. conn (b1 ko'a ko'e) (b2 ko'a ko'e) which reduces to SK as follows
\conn. \b1. \b2. \ko'a. \ko'e. (conn (b1 ko'a ko'e))                                 (b2 ko'a ko'e)
\conn. \b1. \b2. \ko'a. S (\ko'e. conn (b1 ko'a ko'e))                   (\ko'e. (b2 ko'a) ko'e)
\conn. \b1. \b2. \ko'a. S (S (\ko'e. conn) (\ko'e. (b1 ko'a) ko'e))            (b2 ko'a)
\conn. \b1. \b2. \ko'a. S (S (K conn) (b1 ko'a))                                     (b2 ko'a)

\conn. \b1. \b2. \ko'a. (S (S (K conn) (b1 ko'a)))                              (b2 ko'a)
\conn. \b1. \b2. S (\ko'a. S (S (K conn) (b1 ko'a)))                 (\ko'a. b2 ko'a)
\conn. \b1. \b2. S (S (\ko'a. S) (\ko'a. S (K conn) (b1 ko'a)))            b2
\conn. \b1. \b2. S (S S (S (\ko'a. S (K conn)) (\ko'a. b1 ko'a)))         b2
\conn. \b1. \b2. S (S S (S (S (\ko'a. S) (\ko'a. K conn)) b1))             b2
\conn. \b1. \b2. S (S S S S S (K conn) b1) b2

And now I'm bored, but I think that this was illustrative.
Other things you may want to look at: combinatory logic, concatenative programming (or stack-based programming), point-free style (or tacit programming), and the J programming language.

--And.

On Thu, Jul 12, 2012 at 6:44 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com>> wrote:

    .arpis., On 12/07/2012 23:09:

        The common way (speaking as a computer scientist) of avoiding variable repetition (and variable naming issues) in formal methods is to use De Bruijn indices (https://en.wikipedia.org/ wiki/De_Bruijn_index <https://en.wikipedia.org/wiki/De_Bruijn_index>), but this fails the requirement of fitting in human memory.

    Can you give an example of how it would work if applied to a predicate--argument structure? I can't follow the wikipedia article enough to see how it would work (-- setting aside the memory limitation problem you mention).

        On Thu, Jul 12, 2012 at 2:31 PM, And Rosta <and....@gmail.com <mailto:and....@gmail.com> <mailto:and....@gmail.com <mailto:and....@gmail.com>>> wrote:

             Let me try harder to explain:


             Take a variety of predicate logic consisting of predicates, quantifiers and variables. In normal predicate logic notation, if a given variable is an argument of more than one predicate, it gets repeated. And every bound variable is notated at least twice, once where it is shown bound by quantifier and once where it is argument of a predicate. But this is one and the same variable; the repetition is a mere notational device necessary to linearize the string.

             If the notation could be two dimensional, then you wouldn't need to write variables at all. For simplicity's sake, I'll describe a notation for only predicates and variables:
             Use a 2 dimensional grid, infinite in both dimensions.
             Each 'row' corresponds to a variable.
             Each 'column' corresponds to a predicate.
             Predicates are notated by sets of symbols, one symbol for each argument place. Each argument place symbol is placed on the appropriate row for the variable that fills the argument place.

             That's the basic data structure for predicate--argument structure. A 2-dimensional notation can notate it without redundancy. But spoken language is 1-dimensional. Is there a way of linearizing predicate-argument structure ergonomically, in such a way that it is not so verbose or so taxing on the memory that the advantages of its logical explicitness and unambiguousness are not outweighed?

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[Escape Landsome]

De Bruijn indices, --- or, at least, some kind of indices ---, are
required in any semantic theory.

This is because of the constraints due to syntax. Some syntactically
equivalent phrases need to be labelled as refering to the same object,
or to different objects.

Consider the following utterance :

"the black cat looks at the small cat"

Some syntactico-semantic coding would be something like :

lookat(black(cat),small(cat)).PRESENT

or maybe

lookat((cat.black.the),(cat.small.the)).PRESENT

But then, this is not satisfactory since we must also encode somewhere
that the two objects designed by the noun phrases are distinct (or are
the same)

So, à la SOWA, you could code something like :

lookat((cat.black.the)[1],(cat.small.the)[2]).PRESENT

the [1] and [2] things being different.

Sometimes, you will have the same indices, when the objects are the same.

Yet, this is not so simple, because in "You are not you", which is a
philosophical statement about you, one could argue that in some sense
YOU are the same YOU, and in another sense, both YOU are different.

Another problem lies in the mass noun, because a set { a, b, c } is
different than a set { a, b, d }, so, will we say that {a, b, c} is a
[1] and {a, b, d} a [2], or encode it otherwise ? If we opt for the
former solution, the indices notations [1] and [2] show us clearly
that {a, b, c} and {a, b, d} are not the same individuals, but they
fail to encode the common elements a and b which pertain to both sets.

Thus, a good semantic index ought to be some kind of semantic distance
within some semantic space, but this is too complex to be encoded in a
single word or a few ones.

--esc

[John E Clifford]

Alas, &, I think, still wants to have a language.  Combinatory logic and its ilk (all the other versions of computable functions) notoriously don't give languages that one can speak.  So there is an added constraint and one which, I think, pretty much means that the fullest form of an &lang isn't possible.  As long as there is only one term,  there are no (well, very few and easily surmounted) problems.  But the second term, maybe even if it can be specified from the first, does create inevitable discontinuities in a linear structure, and there is no obvious way to bridge those gaps but by anaphoric forms of some sort.  As noted, the fact that the structures can be set up to give each term a canonical introduction does simplify these repetitions by avoiding needing to refer to buried occurrences in some way.  On the other hand, talking about combinatory logic and the like does call to mind languages without terms at all, only predicates, which are feasible (and might actually be useful for testing SWH), but are a long way from FOL and the clarity that is said to reside there (so far as I know --I've never seen anyone work on the issue).

---

From: .arpis. <rpglover...@gmail.com>
To: loj...@googlegroups.com
Sent: Friday, July 13, 2012 1:05 PM
Subject: Re: [lojban] &Lang

To unsubscribe from this group, send email to lojban+un...@googlegroups.com.

[Gleki Arxokuna]

For those who think that lojban isn't enough.

http://loccan3.wikinet.org/wiki/Main_Page

http://tech.groups.yahoo.com/group/jboske/ might be a good discussion platform as And suggested.

[And Rosta]

.arpis., On 13/07/2012 19:05:

Either I've misunderstood your response, or you've misunderstood the challenge. The challenge is that the same bound variable need never be repeated. Sure for any given single sentence containing n different variables you can define an equivalent single predicate with n arguments, but you can't do this for each of the infinitely many sentences in a language.

> Other things you may want to look at: combinatory logic,
> concatenative programming (or stack-based programming), point-free
> style (or tacit programming), and the J programming language.

Thanks for taking the trouble to make the suggestions, but I don't have the requisite intellectual skills to scan outlines of those areas in the hope of descrying a notation that doesn't require variable repetition. If you think one of them provides a notation that doesn't require variable repetition, it would be very precious to meif you were to explain it to me.

--and.

[.arpis.]

Either I've misunderstood your response, or you've misunderstood the challenge. The challenge is that the same bound variable need never be repeated. Sure for any given single sentence containing n different variables you can define an equivalent single predicate with n arguments, but you can't do this for each of the infinitely many sentences in a language.

But you _can_! That's how you'd build up sentences if the language's mechanism for composing concepts involves uniting them into larger predicates.

That said, I have internally equated what you desire to a well-studied notion in computer science (which would need adaptation before being moved to natural language). I may have misunderstood, but I think that your notion of eliminating repeated references is equivalent to eliminating explicit references altogether.
 

Other things you may want to look at: combinatory logic,
concatenative programming (or stack-based programming), point-free
style (or tacit programming), and the J programming language.

Thanks for taking the trouble to make the suggestions, but I don't have the requisite intellectual skills to scan outlines of those areas in the hope of descrying a notation that doesn't require variable repetition. If you think one of them provides a notation that doesn't require variable repetition, it would be very precious to meif you were to explain it to me.

Combinatory logic provides a notation based on S and K (or another one based on B, C, K, and W) for expressing predicates without explicit reference.

Concatenative programming uses the idea of a stack to avoid explicit reference.

The J Programming Language uses ideas from the above to be very terse and linear without explicit variables.
 

--and.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to loj...@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.

[And Rosta]

.arpis., On 14/08/2012 17:30:

> > Either I've misunderstood your response, or you've misunderstood the
> > challenge. The challenge is that the same bound variable need never
> > be repeated. Sure for any given single sentence containing n
> > different variables you can define an equivalent single predicate
> > with n arguments, but you can't do this for each of the infinitely
> > many sentences in a language.
>
> But you _can_!

Ah, so I did misunderstand your response.

> That's how you'd build up sentences if the language's mechanism for
> composing concepts involves uniting them into larger predicates.

I wish I'd been able to understand your worked example, then, because that's the direction where I think the solution lies: iteratively uniting two predicates into one, with a method for indicating which argument-places merge into a single argument-place, ideally without having lexicosyntactically *explicit* variables filling argument-places.

E.g. F(a,b) and G(c,d) merge into a compound predicate H(a,b=c,d).

(My own unpublished solutiontakes this approach, with an inflectional machinery for encoding how two argument lists (e.g. <a, b> & <c, d>) merge into one (e.g. <a, b=c, d>).)

> Combinatory logic provides a notation based on S and K (or another
> one based on B, C, K, and W) for expressing predicates without
> explicit reference.
>
> Concatenative programming uses the idea of a stack to avoid explicit
> reference.
>
> The J Programming Language uses ideas from the above to be very terse
> and linear without explicit variables.

Thanks for that, and I appreciate that you may well lack time or inclination to explain further, but if I'm to understand these promising-looking ideas, I'd need a lot more handholding.

--And.

[Jorge Llambías]

On Tue, Aug 14, 2012 at 10:55 PM, And Rosta <and....@gmail.com> wrote:
>
> [...] that's

> the direction where I think the solution lies: iteratively uniting two
> predicates into one, with a method for indicating which argument-places
> merge into a single argument-place, ideally without having
> lexicosyntactically *explicit* variables filling argument-places.
>
> E.g. F(a,b) and G(c,d) merge into a compound predicate H(a,b=c,d).
>
> (My own unpublished solutiontakes this approach, with an inflectional
> machinery for encoding how two argument lists (e.g. <a, b> & <c, d>) merge
> into one (e.g. <a, b=c, d>).)

I guess that means you need Bell number B(n) of inflections per
connective for predicates that together have n arguments. This number
grows pretty fast with n, http://en.wikipedia.org/wiki/Bell_numbers
but I guess you must have some way of compositionally creating the
inflections so they are manageable,

mu'o mi'e xorxes

[And Rosta]

Jorge Llamb�as, On 15/08/2012 23:13:

I don't think it is Bell number, since the Livagian system requires 1--1 correspondences between members of the two sets, whereas Bell number seems to be the number of possible correspondence patterns among members of a set. Each member of each of the two sets may be in correspondence with either exactly one member of the other set or no member of the other set. For reasons I won't go into, there are four different sorts of correspondence. So, each member of each of the two sets is either in exactly one sort of correspondence with either exactly one member of the other set or is in no correspondence with any member of the other set. That must be an easyish formula to find for somebody with more maths nous than me.

And yes, the inflections are compositional.

--And.

[Jorge Llambías]

On Fri, Aug 24, 2012 at 5:34 PM, And Rosta <and....@gmail.com> wrote:
> Jorge Llambías, On 15/08/2012 23:13:

>> On Tue, Aug 14, 2012 at 10:55 PM, And Rosta<and....@gmail.com> wrote:
>>>
>>> E.g. F(a,b) and G(c,d) merge into a compound predicate H(a,b=c,d).
>>

>> I guess that means you need Bell number B(n) of inflections per
>> connective for predicates that together have n arguments.
>

> I don't think it is Bell number, since the Livagian system requires 1--1
> correspondences between members of the two sets, whereas Bell number seems
> to be the number of possible correspondence patterns among members of a set.

So you can't have F(a,b) and G(c,d) merge directly into H(a=b=c, d).

Then the nth Bell number is the number of unary mergers that you need
for predicates with n arguments, the binary mergers will be fewer
(assuming you can make use the unary mergers first). But presumably
you could also do the unary mergers in steps, with only two arguments
merging at each step, so for an n argument predicate you only need
n(n-1)/2 mergers. Which you could also reduce by combining them with
argument shuffling operators.

> Each member of each of the two sets may be in correspondence with either
> exactly one member of the other set or no member of the other set. For
> reasons I won't go into, there are four different sorts of correspondence.
> So, each member of each of the two sets is either in exactly one sort of
> correspondence with either exactly one member of the other set or is in no
> correspondence with any member of the other set.

OK, that's a smaller amount of correspondences than I was thinking of.

> That must be an easyish
> formula to find for somebody with more maths nous than me.

If my calculations (for a single sort of correspondence) are correct:

N(n,m) = Sum from i=1 to min(n,m) of n!m! / i!(n-i)!(m-i)!

N(n,1) = n
N(n,2) = n(n+1)
N(n,3) = n(n^2+2)

Probably this number has a name, but I don't know what it is.

For four sorts of correspondence, it gets more complicated.

>
> And yes, the inflections are compositional.

The nth Bell number is the number of different compositions you need
to cover all cases of n arguments. (With one kind of merge. With four
kinds of merge, I don't know.)