Add methods to declare atom types in Python modules dynamically

[vsbogd]

No description provided.

[linas]

Looks good to me.

What do you plan to do with this?

[linas]

I merged because this is simple enough that it didn't seem to need discussion....

I still would like to know .. what do you plan to use this for?

[vsbogd]

I would like to create new Node and Link types for experiments but using cmake infrastructure in Python project is not convenient. Dynamic atom types creation should be used with caution with atomspace persistence layer, but I think we will not use persistence in experiment scripts. And after that we will think about approach. If code is shared between Scheme and Python it is better to introduce new atoms as separate C module.

I hope new atom types will simplify atomspace queries. Atom types can be designated using InheritanceLinks or EvalutionLinks but this approach is more verbose.

[linas]

Dynamic atom types creation should be used with caution with atomspace persistence layer,

This should mostly-kind-of work. The postgres layer stores atom types as numbers, and has an atom-name-to-number lookup table. If the SQL tables know about an atom type that the C++ code does not, it is ignored. (this should be changed so that the unknown type is created, which is not easy because the SQL tables do not store the inheritance hierarchy.)

The RocksDB stores atom types by name. I'm not sure what happens if the RocksDB holds an atom type that the C++ code does not know about. The RocksDB does not store the atom type hierarchy. This should be fixed. BTW RocksDB is 3x or 5x or 10x faster than postgres!

If the above two are fixed, then it might happen that python still won't know about the new atom types. I don't know how that works. Similar remarks for scheme.

See #2789 and opencog/atomspace-rocks#6 and #2790 and #2791

new atom types will simplify atomspace queries

Yes, they would.

Atom types can be designated using InheritanceLinks or EvalutionLinks but this approach is more verbose.

Yes. The wiki details the theory of this in greater detail but that theory is not really implemented. Even though it is more verbose, it might make it easier to interface with PLN and/or other subsystems. That is, it should be possible to "introspect" atom types in Atomese. To examine the type hierarchy by running an ordinary BindLink/GetLink. No one has needed this, yet. Hmmm This might be the easiest way to extend new atom types into persistence!?