-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flexible transient execution #2752
Comments
Pretty much all of the commands in https://github.com/opencog/atomspace/blob/master/opencog/persist/sexpr/Commands.h can be converted to atomese. Here's a quick sketch.
The
For a general fetch...
Some kind of
Can this be more join-link like ...??
All of these suffer from the same two problems:
So maybe the performance tradeoff is not that big a deal? ditto
|
|
So this is mostly about a flexibility vs. performance tradeoff. Just how much of a performance hit is there? It might be minor. The other tricky part is that the Can this work? It's a pretty major redesign... |
The scheme bindings (and the python bindings, too, I guess) have a certain core subset of functions that are very commonly used, and should be converted to Atomese. For example,
could be written as
This is "a good thing" as it reduces the amount of custom scheme (or python) code needed -- the
cog-execute!
becomes the one place to do all the work.The "bad thing" is that this implies that
(IncomingOf (SomeAtom))
is a valid Atom, to be stored in the AtomSpace. It is a bit of a waste to store it -- it clogs up RAM, when the "typical" user probably just wanted to get the incoming set, and nothing more. This can be solved by inventing a newcog-execute-transient!
function, that works like so:It will create an instance of
SomeExecutableAtom
, then run it (passing inSomeOtherAtom
as an argument) and then return the result as aLinkValue
(per issue #2530) TheSomeExecutableAtom
will NOT be placed in any AtomSpace! Thus, it disappears right after being used.This is particularly desirable for things like the cogserver, and atomspace-to-atomspace communications, where we just want to run some commands remotely, and get answers back (see, for example both https://github.com/opencog/atomspace-cog and also see https://github.com/opencog/atomspace/blob/master/opencog/persist/sexpr/Commands.h )
The text was updated successfully, but these errors were encountered: