opencog-dev team mailing list archive

[Cassio Pennachin <cassio@xxxxxxxxxxxxx>]

I don't see why we should have to choose a language, really, although  
I really like CL or Scheme for this.  If we can create bindings for  
one language, we can probably do it for multiple languages without too  
much extra work -- nearly zero if SWIG is usable.

A more important point is an architectural one, however.  There are  
two different subsets of OpenCog we may want to make available to code  
in other languages:

1. libAtomSpace.  This allows people to prototype AI code (e.g. PLN  
was initially implemented using this approach, through the more  
cumbersome path of implementing a very simplistic atom table with a  
similar API), but it doesn't provide MindAgent services nor CogServer  
dynamics.  This is easiest to do, and very, very useful for developing  
novel AI modules.

2. The CogServer proper.  I'm not sure this can be done by any of the  
proposed approaches save what Linas has been doing: telnet into the  
server.  This is also what nmsh does.  The CogServer is soon going to  
be multithreaded, with dynamic MindAgent plugging and other niceties.   
All of this makes less sense in a library than in a server, but is  
needed if one 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.

Thoughts?  Does the above sound clear or confusing?

Cassio

On May 29, 2008, at 2:51 AM, Ben Goertzel wrote:

> After more thought, I strongly agree with Moshe and Linas that a LISP
> flavor is going to be our best bet in terms of making OpenCog
> scripting compact and simple
>
> Whether Scheme or some other LISP variant is the best bet is another  
> question
>
> I am personally partial to Scheme syntax ... or at least I was in the
> 90's when I knew it ... but I feel less strongly about this than about
> the preferable-ness of LISP over Python or Ruby for this purpose
>
> ben
>
> On Thu, May 29, 2008 at 12:49 AM, David Hart <hart@xxxxxxxxxxxx>  
> wrote:
> > [NB: moved thread to opencog-dev list]
> >
> > For what it's worth, I'll put my hand up for a Python shell and SWIG
> > wrappers. The ability to quickly bung things together (like visual  
> > analysis
> > tools) with python libraries is very compelling.
> >
> > If it's well documented, can we have a mix of SWIG wrappers and  
> > hand-wrapped
> > functions for the things that SWIG doesn't do nicely or optimally?
> >
> > I also like the idea of python-based cognitive architecture files
> > (basically, the primary OpenCog config file, a python script used to
> > bootstrap a CogServer), once enough of the parts are pluggable.
> >
> > Thoughts? /me sprays on flame retardant
> >
> > -dave
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~opencog-dev
> > Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/people/+me/+editemails
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Ben Goertzel, PhD
> CEO, Novamente LLC and Biomind LLC
> Director of Research, SIAI
> ben@xxxxxxxxxxxx
>
> "If men cease to believe that they will one day become gods then they
> will surely become worms."
> -- Henry Miller
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/people/+me/+editemails
> More help   : https://help.launchpad.net/ListHelp

--
Cassio Pennachin
CEO, Vetta Labs
www.vettalabs.com -- +55(31)3421-6933