← Back to team overview

opencog-dev team mailing list archive

Re: OpenCog Shell

 

We don't care about preserving the syntax of Combo at all ...

And we don't have a huge amount of legacy Combo code that we care
about ... most of the Combo code written was for the AGISim prototype
project, which is pretty much obsolete...

What we care about are, initially, the methods of Atom and core
manipulation described in NovamenteComboDescription...pdf

Sorry for the unclarity!
ben

On Mon, May 26, 2008 at 11:49 PM, Linas Vepstas <linasvepstas@xxxxxxxxx> wrote:
>
> 2008/5/26 Ben Goertzel <ben@xxxxxxxxxxxx>:
>>
>> How much effort do you reckon it would be to extend this into a Scheme
>> front end for the Combo language that currently exists in the Novamente
>> core (which Moshe wrote a while back)?
>
> I'm not sure I understand the question. Guile is a full-fledged
> scheme interpreter; and scheme is a full-fledged
> programming language (its lisp with assorted technical
> stuff added, e.g. central use of tail-recursion)  You'd
> want to put combo on top of scheme, rather than vice-versa.
>
> All that I've done is to add code to make opencog atoms
> be "primitives", so that any scheme code can manipulate
> them as regular, first-class entities. You can run any scheme
> code whatsoever within the interpreter ... e.g. compute pi to
> six digits, and then create an atom with that value as its
> string name.  You can pass atoms around as arguments
> to functions, as elements in lists, trees, etc. in a
> "transparent" fashion.
>
> The syntax for combo is similar to, but different,
> from scheme.  If its important to maintain syntatic
> compatibility with combo, then one would have to write down
> a BNF grammar for combo, and feed it to some parser
> of your choice; I believe there are many out on the net.
> But this makes sense only if you already have a lot of
> code written in combo, and you want to get it running.
> But I don't believe that this is the case?
>
> Is it critical to have the exact same syntax? What core
> concept are you trying to preserve? I presume that
> what you really want to do is to run the evolutionary
> learning code. If I understand correctly, then what
> you really need is the ability to convert arbitrary lambda
> expressions into combinator strings, and back, is that
> right?  If so, I think this is doable: One should be able
> to take any arbitrary scheme expression and turn it
> into a combinator string, and turn it back.
>
> The ability to convert to combinators and back is
> orthogonal from the ability to manipulate atoms, though ...
> the fact that some  variables or constants might be atoms
> is beside the point ...
>
> --linas
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "OpenCog.org (Open Cognition Project)" group.
> To post to this group, send email to opencog@xxxxxxxxxxxxxxxx
> To unsubscribe from this group, send email to opencog-unsubscribe@xxxxxxxxxxxxxxxx
> For more options, visit this group at http://groups.google.com/group/opencog?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>



-- 
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



References