From me@nellardo.com Thu Jan 24 11:40:02 2002 Return-Path: X-Sender: me@nellardo.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_0_1_3); 24 Jan 2002 19:40:02 -0000 Received: (qmail 33854 invoked from network); 24 Jan 2002 19:40:00 -0000 Received: from unknown (216.115.97.167) by m3.grp.snv.yahoo.com with QMQP; 24 Jan 2002 19:40:00 -0000 Received: from unknown (HELO mail6.speakeasy.net) (216.254.0.206) by mta1.grp.snv.yahoo.com with SMTP; 24 Jan 2002 19:40:00 -0000 Received: (qmail 19137 invoked from network); 24 Jan 2002 19:39:59 -0000 Received: from unknown (HELO dsl027-135-047.nyc1.dsl.speakeasy.net) ([216.27.135.47]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Jan 2002 19:39:59 -0000 Date: Thu, 24 Jan 2002 14:39:58 -0500 Subject: lojban as a programming language [was Re: [lojban] Lojban for lay programmers] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: lojban@yahoogroups.com To: bob@rattlesnake.com In-Reply-To: Message-Id: <267B5602-1102-11D6-9015-003065B787D6@nellardo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) From: Brook Conner X-Yahoo-Group-Post: member; u=66018878 X-Yahoo-Profile: nellardo In the spirit of "No thread here ever really dies...." On Wednesday, January 23, 2002, at 05:32 pm, Robert J. Chassell wrote: [snip on Knowledge Home] > Next week I am going to a workshop sponsored by the Institute for > ScientificI think of Lojban as potentially more sophisticated for a > `scripting' > or `verbing' language for the the `Knowledge Home' project than Emacs > Lisp or Python. Those are two programming languages that have been > mentioned so far as possible `scripting' or `verbing' languages for > educated, non-programmers for this project. Okay, quickie - if they're considering Emacs Lisp, they should look at Scheme instead. Guile (guile.org) is a nicely embeddable scheme interpreter. Now, back to lojban. This was something I brought up a couple years back - lojban used as a programming language. It especially shines as a spoken programming language, because its phonemic structure matches lexical structure - much easier (in theory) for the computer to catch lexical or grammatical errors and then recover from them. No, the tricky part is not parsing lojban - as you point out, the yacc grammar does that. The tricky part is the *semantics*. Any single word in lojban has only one definition (but be careful - this doesn't apply to names - see below), but what that definition means when applied to actual operating semantics is something else. For example, when evaluating a lojban sentence, do you use strict evaluation or lazy evaluation? I'm talking machine semantics here, not parsing syntax. The canonical example from programming literature for the difference between strict and lazy is something like the following: if: true Then: 0 Else: (1/0) -- smalltalk syntax if statement A strict language evaluates every argument before dealing with the function call while a lazy one does not. The above statement causes a run-time error with a strict language (divide by zero in integers - very bad), but happily returns 0 in a lazy language (it doesn't bother to do the divide by zero because the answer is never needed). This kind of example is even easier in lojban: la flubar. mekso li no te'a ni'u pa "foobar" is the-expression the-number zero raised to the -1. A lazy language will happily pass around la flubar. but a strict one will throw a divide-by-zero error. "But wait!" you cry! lojban has the answer! ci'i is the word for infinity! Two problems with that. 1. this is only one example - infinite loops run into the same kinds of problems. 2. Strictly speaking, ci'i is not a number. Oh sure, it may be a transfinite number (ci'i no, ci'i pa, etc.), but a transfinite number is definitely not in the set of integers, rationals, or even real numbers (mathematically speaking, IEEE floating point numbers are none of these, are not even a group (I don't think NaN has an additive inverse, and Inf has very peculiar behavior)). [snip] > (2) able to be used (with a subset of the > vocabulary, but the same grammar) as a computer scripting language, Another problem of semantics is choosing the subset of the vocabulary and making sure the user knows what it is. Are you going for an imperative model? Lots of "ko" running around. Or a declarative model? This suits lojban better, but has its own issues to deal with. For example, some lojban statements are inherently stateful, e.g., the word to reset the counted pronouns. Both of these have issues of name space and scope that are not an issue in a human language - two identical names can be clarified with additional clauses. Computers tend to simply barf. [snip] Don't get me wrong - another parser for lojban is great, but designing the semantics, even for mekso, to a level where a computer can predictably deal with it (and deal with it in a manner comparable to a human) is not as simple as it might first seem. -- Klactovedestene!