Re: [lojban] &Lang

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. <rpglover64+jbobau@gmail.com>
To: lojban@googlegroups.com
Sent: Friday, July 13, 2012 1:05 PM
Subject: Re: [lojban] &Lang

On Fri, Jul 13, 2012 at 10:31 AM, And Rosta <and.rosta@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.rosta@gmail.com <mailto:and.rosta@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.rosta@gmail.com <mailto:and.rosta@gmail.com> <mailto:and.rosta@gmail.com <mailto:and.rosta@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 lojban@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.

--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to lojban@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.