So, as I understand your overall = design you’re talking about a unifying application framework with some = fancy (or simplistic depending on your POV) recursion to take care of chaining = things together.

Forgive me for sounding cynical, = but how is that different from .NET (and its IL)? I suppose the positivist = translation would be “what problems does this system = address?”

--M@

From: lojban-list-bounce@lojban.org [mailto:lojban-list-bounce@lojban.org] = On Behalf Of Andrii Zvorygin
Sent: Sunday, September = 24, 2006 1:36 PM
To: = lojban-list@lojban.org
Subject: [lojban] Re: my = opinion on why lojban isn't specifically well suited for human-computer = interaction

It all depends on how you design the =
interface. I agree that classical computing wouldn't work with a lojban =
interface in an intuitive way. Because classical computing is very =
haphazzard, we have monolithic applications (though many of them are =
modularizing). Our computers aren't really wholes, they are just a bunch =
of standalone applications, thrown together. with lots of duplicate =
code. Sure linux is improving we have libraries, but the problem is we =
have libraries for every single programming language that more or less =
do the same things.





if we broke up the programs into functions, then we could re-use =
functions from one program in another program. If you say, ran programs =
in a lojban interpreter, and

say the function printed to it's stdout "cusku lu .ui roda drani =
li'u zo'e la skrin."



that would be recieved by the interpreter, and it would (assuming la =
skrin. was actually a handle for the screen),

it would print to screen: <function name> cusku lu .ui roda drani =
li'u

or whatever the user or implementation defined as should be done with =
that kind of output.





so say then we need a way of handling these large amount of bridi and =
selbri and all their possibilities. so we could (while files still =
exist), make a few files in a directory structure to describe what is =
happening,





say we have a  head directory lokrasi/selbri/

this directory will contain directories of all the selbri (including =
lujvo and fu'ivla, or anything with a function)



so going with our cusku example

>lokrasi/selbri/



>lokrasi/selbri/cusku/



in each selbri we could have a description file for what this function =
does say

>lokrasi/selbri/cusku/cusku



now cusku could contain, the input and the possible output, perhaps just =
a generalization, and specific inputs and outputs can be handled later. =
lets take something a little less complicated than cusku temporarily =
(because it doesn't have any real =
ouput.





so

>lokrasi/selbri/valsi/valsi

could say on some line:

>xu zo ko'a valsi fi la lojban. ja'e lu go'i .a na go'i li'u

which would allow for you to use the valsi function to ask for wheather =
or not it is a word.





some other examples of  General Bridi:

>zo ko'a valsi ma la lojban ja'e lu da li'u

in :

>lokrasi/selbri/fanva/fanva

>zo'e fanva zo ko'a la .inglyc. la lojban. ja'e zoi .gy. da .gy.



then you could have (possibly we could think of something better latter, =
works for now)



>krasi/valsi/xuzoko'avAlsifilalOjban.ja'elugo'i.anago'ili'u



The lines in this file might partially be written by hand, but it is =
thought that eventually this file will be written to based on actual =
input and output.



then in this file (specific bridi) you would have lines looking =
like:

>xu zo valsi fi la lojban ja'e lu go'i li'u

>xu zo thn fi la lojban ja'e lu na go'i li'u







General Bridi, and Specific Bridi, would have at least a few forseable =
uses:



* verification of functions (if you get a new function off the network, =
that say works faster, or takes up less room, has some security fix, the =
Function Manager, that would be doing this update, can stick the =
function in a sandbox and test out what it outputs, and makes sure it =
doesn't give false output, or try to access any files(to avoid malicious =
software))



* creation of functions (by humans): the input and output of the command =
would definatly be very helpful in creating a new function, as well as =
seeing the general function to understand what is happening.

* creation of function (by AI): because the input and output is so well =
defined as well as the format, it is forseable that you could evolve =
functions to preform the same operation with smaller executable =
size/faster speeds. you wouldn't let it work with all input and output, =
you should have some to see if it could predict the input output (not =
something like fanva though, where it's just =
translation)



* simulation of function (by skami): If the function for some reason =
broke, or no longer exists and you have previous input and output, you =
could then just give the output when you see the input.



Now comes the rather obvious problem of what do you do with functions =
that are not sateless (that can give different outputs with the same =
inputs). this is a little more complex, but the idea is to have the =
skami monitoring the program upon execution, and trying to see which =
environment variables seem to influence the output and then correlating =
them.





so something like cusku could have a General Bridi of:

cusku ko'a zo'e la skrin. ja'e lu la skrin. ca vasru ma ja'e fo'a .i =
fo'a vasru  lu  cusku ko'a zo'e li'u li'u



now this is all great for if you have very small applications but say =
you want to have a mode or something, for editing documents, vi =
style:



>kavbu la'i zoi zoi j zoi lerfu fi function

>ce zoi zoi k zoi  lerfu fi function2 

>ce zoi zoi d zoi  lerfu fi function3

>ce zoi gy. : .gy. lerfu fi function 4



or something of the like, really will depend on the actual =
implementation once more code get =
written.





I was thinking that optionally you could also have a MUD, that would =
help navigate through the API, and large programs, and make it really =
easy to change the current view, modify or add in new links in the chain =
of output from one function to =
another.





also optionally you could make a transitional-programming language in =
lojban, though i don't mean to actually have a lojban programming lojban =
language (that would be most of the above described) i mean a =
translation for current programming languages, so that you don't have to =
remmber that in bash you use if [[ a=3D=3Db ]];then ;fi and in java you =
use if { a =3D=3D b } {}, just have it so you could translate from java, =
to this transitional format, and translate back into java, or perhaps a =
different language in the same class, it could (conceivably) be =
achieved.





lojban programming language, if such a thing will really exist as a =
whole, would probably be a more or less pure functional programming =
language. like Haskell

The planning of this development environment / interface, is still in development so please feel free to contribute. i got some of the sources = available:

http://lokiwor= ld.org/mediawiki/index.php/Funcysam

note: have to edit the website to include this description probably will = put this email there, this is probably the first time i've summarized most = of my ideas for it.

9/24/06, M@ <matthew.dunlap@gmail.com>= wrote:

First, a disclaimer; while I have put a significant amount of time into = thinking about this kind of thing I'm certainly not an expert. I'm still going = for my BS.

Computers are both digital and binary (note: I distinguish digital from binary, = some people disagree, but that's another argument altogether (and yes I'm = aware that binary implies digital, that phrase is foreshadowing)), which makes them = an interesting self metaphor. The difference between MI and AI is as fundamental as the difference between 1 and 0. Thus, the two = potential uses of a syntactically unambiguous language (SUL for brevity) in a = computer have no grey area between them.

The short term use (dream) is to teach computers to utilize the language's unambiguous nature to provide an interface that can be read and written = to in a spoken language. Obviously in a classical (ie linear processor = based) computer syntax ambiguity is a severe no-no because the correct = (intended) parsing is a non-digital process. Initially it's very tempting to = say, oh, here's a language that sidesteps that problem by eliminating syntax ambiguity, we should use it to provide a more natural interface! = And yes, that goal can be reached in a year or two with devoted work. =

The problem I have with this goal is that it's a solution to a problem that = has been solved for decades. There are many SULs that are already = written and in use as computer interfaces across the world. My personal = favorite is bash. To compare bash to lojban I would say that bash is easier to = learn (it is much smaller after all) and every bit as versatile as a cross-programming-language interaction framework as lojban could = possibly be in a classical computing environment. Both languages are equally not = my first, and I would say I'm truely fluent in neither, but comfortable = with both. Of course, it is possible that in the near future there will = be core (to borrow a term from the ASL community) jbopre, but even they = will find the system is as unintuitive as any other digital language processing = system (even with AI assistance) because of the restrictions requiring digital formatting. Another way to say it, is no matter how hard you try classical computers will never be able to figure anything, they rely on unambiguous meanings to get things done, lojban doesn't necessarily = provide that, bash does.

The real beauty of lojban isn't the fact that it's a SUL. The real = beauty of it is a consequence of being a SUL, and that is, it can be used to = convey things in absurdly creative (ie anything but digital) ways. As = with any real beauty there is always a converse beast, which in this case is the = fact that it's silly to be more creative than the person (or computer) you're talking to. Anyone who has dealt with the people that work at a = DMV knows exactly what I'm talking about.

Lets look at a very simple example that directly relates to an everyday = computer activity in a lojban based classical computer = system.

ko minde mi> la zgikeB.mp3 fukpi la = zgikeA.mp3

je'e

The computer had no problem using with the command because it was in the = finite list of things it is programmed to do, but if I throw even the simplest creative twist into the command it breaks out of the list of functions = and the computer has difficulty.

ko minde mi> la zgikeC.mp3 fukpi la cdrom0 le mp3 la = ripperprogram

.a'onai je'enai

ko minde mi> ko facki go'i

.a'onai je'enai

ko minde mi> .o'onaisai

This example was designed to illustrate two specific problems with a = linguistically interfaced classical computers. Yes, the first command could have = been simplified to "la zgikeC.mp3 ripperprogram la cdrom0 le mp3" = and it probably would have worked, but what if there was some desired = functionality that fukpi provided (a cvs push or something)? That aspect of the operation would then have to be done in a separate command. To = interpret the command correctly the fukpi programming would have to figure out how = to use whatever x4 argument you could send it, but the nature of the language = makes that impossible without understanding the meaning of the words in the x4 = place, simple recursion won't do it.

The second thing I'm pointing out here is that 90% of the people I sit at a = modern command prompt don't understand the limitations of the system, so they intuitively assume that it speaks whatever language the OS prompts are in. Then they try to talk to the computer through the keyboard and = are frustrated when it doesn't work. It's freaking hilarious sometimes = ( http://blog.myspace.com/index.cfm?fuseaction=3Dblog.view&friendID=3D7= 7851792&blogID=3D130868121&Mytoken=3D26C6508D-0CAC-43BB-BDA1B437D= CB0AA7811819937 is a candid transcript of one such occasion), but it's remarkably non-productive.

Of course, the other dream is to actually teach a MI how to speak and = understand lojban. Assuming such an auto-associative system could be made = hardware wise, there would be absolutely nothing preventing it from being a = perfectly natural feeling interface in spoken or typed lojban. You could ask = it absurd questions and it could give you obviously considered = answers. The problem I find with this is that once you've built MI there's no reason whatsoever you couldn't teach it English as = well.

The problem with human languages is that they are based on = understanding. The problem with computer languages is that they're based on digital = principles (which don't really apply in an analog = world).

That's what I think anyway, if you disagree I'd love to hear = why.

--M@