Re: lojban as a programming language [was Re: [lojban] Lojban for lay programmers]

[Brook Conner <me@nellardo.com>]

On Thursday, January 24, 2002, at 03:36  pm, Invent Yourself wrote:
> We actually had a discussion about this a while ago. It revolved around
> the question: does lu'e la djan mean " "John" ", or "a symbol for 
> "John"";
> is it the symbol, or does it mean the symbol?

This is actually a different topic from lazy vs strict evaluation. The 
lazy/strict difference has to do with deciding when to change "lu'e 
<<parsed but unknown>>" to "lu'e la djan."

The meaning of lu'e is a matter of indirection, not time of evaluation. 
The action of lu'e when applied to a name seems pretty clear. Consider 
it this way: lu'e and la'e are inverses of each other. Thus:

la'e lu'e la djan. == lu'e la'e la djan. == la djan.

So lu'e la djan. is a pointer to "la djan." whatever that happens to be. 
In this case, it happens to be a name, which itself can be thought of as 
a pointer to the actual person we call djan. Thus, lu'e la djan. is a 
pointer to a pointer to the actual person djan. and la'e la djan. is the 
actual person. mi visko la'e la djan. I see John (for real, in the 
flesh, directly).


> In Lojban, I think ci'i gets treated just like any other member of 
> selma'o
> pa. And I find that refreshing.

As was noted, syntactically, it is a number. Treating it semantically 
like a number raises all sorts of hairy formal questions. Some 
programming languages have arbitrary precision arithmetic - 
factorial(50) in C just ain't a happy camper, as it has about three 
times as many digits as a 64-bit number:

Prelude> 2^64
18446744073709551616
Prelude> product [1..50]
30414093201713378043612608166064768844377641568960512000000000000

Other programming languages, like haskell (the above code is straight 
from hugs, the most common haskell interpreter), quite obviously have no 
real problem with really big numbers.

> At least it's simple than doing so with any other "full" language.

Any non-constructed language, certainly, as those typically have 
incomplete grammars (at best) and multiple meanings for any given word.

Brook