opencog-dev team mailing list archive

["Linas Vepstas" <linasvepstas@xxxxxxxxx>]

Hi,

2008/5/29 Moshe Looks <holism@xxxxxxxxx>:
>> wants to test their code running in collaboration with other MindAgents,
>> request complex tasks of other MindAgents, etc.
>>
>> The natural way to reach 2 is to embed interpretation of the higher level
>> language within the C++ process.  I know this can be done with Ruby, and I
>> believe it should be possible for some LISP flavor.  I don't know if we can
>> preserve concurrent processing and other server-like abilities by calling
>> the CogServer as a library from a higher level language process.
>>
> I am by no means an expert, but after a cursory examination it seems
> like Embeddable Common Lisp (http://ecls.sourceforge.net/) might
> support this though its dynamic FFI (overview at
> http://ecls.sourceforge.net/new-manual/ch18s02.html), including
> concurrent processing. Of course, this would chain development to ECL,
> but the upside might be worth it (very very cool if it actually worked
> ;->).

There are several distinct issues here.

a) a scripting language. This is used for light-weight duty,
interactive shell work, debugging, rapid prototyping,
maybe even some minor cpu-cycle consuming computation.
"script-fu".

b) library language. this would a a language in which one
could write serious, cpu-consuming mind-agents, and
expect them to run with good performance; comparable to
that of native C++ code.

c) multi-threading.

I expect any/all solutions to be multi-thread safe, lack
of thread safety is a non-starter.

For a), I picked guile simply cause I know it. Perhaps there
are CLOS implementations that support embedding as well.

Now, for point a)
I am confused a bit by "FFI". The idea is not only to handle
foreign objects as primitive data-types, but also to export
these in an interactive shell. That is, the garbage collector
and the evaluator must be able to run, ** in C++ **, the C++
loop
   while (1) {
       char * expr = read_expr_from_user(...);
       char * reply = eval(expr);
       print_to_user (reply);
   }

and eval() does not only the evaluation of the ascii string
holding the lisp code snippet, but also garbage collection &c.

I don't think this is what "FFI" means ... but it is something
that guile was designed to do.

For point b)  I think both scheme and CLOS offer multiple
possible solutions. The most promising scheme compiler
is bigloo, http://en.wikipedia.org/wiki/Bigloo (its can even
generate java jvm bytecode for the java fanatics out there..)
there are many others at
http://en.wikipedia.org/wiki/Category:Scheme_compilers
Oddly, wikipedia doesn't list any compilers for CLOS.
I wonder why.

Anyway, for point b), yes, it would be nice to be able to
write code that looks like (similiaritylink :tv 0.8 (wordnode
"bark") (wordnode "dog")) or whatever, and have it compile
into high-performance code, so that cpu-crunching mind
agents become easy to write *and* fast. There seem to be
a variety of options.

I'm surprised no one said "haskell" yet.

--linas