Re: [Flora-development] [Xsb-development] XSB and Flora-2 wrappers for .NET and Python

[Markus S. <msc...@fo...>]

Dear Michael,

On Thu, 18 Jan 2007, Michael Kifer wrote:

> Hi Markus,
>
> This is very interesting. I need some time to wrap my mind around it
> because of my lack of knowledge of Python.

I'm sorry for not taking this into consideration. I'll try to explain 
further ;-)

>
>> For example lets say we have a python class like:
>>
>> class example:
>>           def __init__( self, a=1, b=[1,2,3] ):

by specifying a=1, and b=[1,2,3] we say that the default values of the a 
and b attributes in class example are 1 and [1,2,3] respectively.

>>                   self.a = a
>>                   self.b = b
>>           def some_func( self ):
>>                   print "Hello from example"
>>
>> to create an instance we use:
>>
>> ex = example()

So ex = example() gives us the same like ex = example( 1, [1,2,3] ).

>>
>> now the power of Python lies in:
>>
>>>>> dir(ex)
>> ['__doc__', '__init__', '__module__', 'a', 'b', 'some_func']
>>>>> ex.__dict__
>> {'a': 1, 'b': [1, 2, 3]}
>>>>>
>
> Forgive my naive question, but what exactly does the above mean?
>
Nothing to forgive, this was my error. It's pretty simple:

dir(ex) gives us all the names of objects which are contained inside 'ex', 
in our example:

__doc__ <- the documentation string of the object (every object in Python 
has automaticly a doc-string)
__init__ <- the constructor method
__module__ <- in which module is this object
a and b <- attributes defined in the class
some_func <- method defined in the class

ex.__dict__ gives us a dictionary (native type in Python; like a 
mapping) with the names and values of the objects attributes. It basicly 
means the value of a in ex is 1, the value of b in ex is [1,2,3] (where 
[1,2,3] is a list; also native type in python).

>
>> So we can query the internal structure of the 'ex' object. An algorithm I
>> allmost finished tries to translate Python objects into F-molecules.
>> Basicly I want it to be
>>
>> ex:example[ a->1, b:list->[1,2,3] ].
>>
>> for now since I'm not 100% clear with the idea of using the object's
>> methods at all or not. I was thinking of using boolean methods as descibed
>> in the manual to have a reference in Flora-2 that a method for a given
>> object exists, but I'm still not sure if it would be of any use.
>>
>> To go further with the concept if we have an object like described before
>> and use logical variables like described in the recipes then we can do the
>> following:
>>
>> X = Variable()
>> qu = example( X, [1, 2, 3] )
>>
>> so we would have a mapping to a F-molecule like
>>
>> qu:example[ a->X, b:list->[1, 2, 3] ]
>>
>> Now by using the concept of rules as described in the recipe we could say:
>>
>> qu << [ ex, [X, 2, 3] ]
>>
>> No real sense in the rule but I hope you understand the Idea. This could
>> then be translated to Flora-2 like:
>>
>> qu:example[ a->X, b:list->[1, 2, 3] ] :- ex:example[ a->1, b:list->[1, 2,
>> 3], [X, 2, 3].
>>
>> So you could basicly use the Flora-2 engine to store data objects from
>> Python applications and then using the concept of rules and logic
>> variables query this objects.
>> I also tought of making the data consisent using ZODB which allows easily
>> to store Python objects. There's also an idea to make it network ready
>> (e.g. to make it possible to run as a knowledge base server which any
>> python program can use over the network using Python NetWork Spaces). But
>> this is still a little idea in my head ;-)
>
> Do you need to define a priori which Python objects can be stored on the
> Flora side? In the high-level Flora-Java interface one has to decide
> beforehand which (Flora) classes and methods are to be reflected on the
> Java side (which is a major drawback and involves a preprocessor), but then
> everything is automatic.

Well since Python has class factories and the (above described) means to 
query the structure of an object this is not necessary. So objects on the 
Flora side would be something like generated copies of real Python objects 
which can easily be reconstructed when back in Python. My idea is the 
following: if I pass an object from a Python program over the network to a 
Flora server, first a descriptor is sent (which could be for instance a 
F-molecule in Flora-2 sintax). The server than creates a dynamic class 
from the descriptor (through a class factory) which lets him construct 
objects on behalf of it. Then the real object is sent to the server side. 
The server side can then manipulate this object since it has a matching 
class descriptor.

This issue was also a problem to me. A pretty big problem is how to use 
internal methods of a Python object as in Flora-2 as well as in a 
client-server architecture. There are two ways (as I figured out) to do 
this: one would be to integrate Flora-2 and Python more closely (e.g. 
manipulate Flora-2 so it can access Python methods), and the second would 
be to let the queries (e.g. some_object[ X(1,2,3) -> 4].) be evaluated 
partly by the Flora-2 engine partly by Python.
The first solution could be pretty much work but possible and after all 
probably much faster than the other. The second would be probably easier 
to implement but possibly slow and maybe not satisfactory (e.g. there 
would be some constraints on using such queries for the user).
This is why I'm now thinking of letting the methods out until I figure 
out a better solution.

>
>> As soon as I have a little bit more usable version of the Python interface
>> I'll let you know. If you have any comments, suggestions, critiques etc.
>> they are very wellcome since I'm not 100% sure that I'm doing thigs right
>> ;-)
>
> Good. When you will have a more self-contained description of the idea I
> would like to see it. Meanwhile I will try to understand the recipes better.

As soon as I find some time I'll try to translate the concept. The 
reciepes just describe how to use logic programming concepts in Python. 
The most valuable idea there is to introduce the concept of logical 
variables into an imperative language like Python. I'm not realy satisfied 
with the concepts of facts and rules described there. But (since Python is 
weakly typed e.g. types are assigned to variables at runtime) it is pretty 
easy to assing logical variables to attributes of objects and use such 
pseudo-objects in queries and rules.


Best regards

--
Markus Schatten, dipl. inf.
e-mail: mar...@fo...
http://www.tiaktiv.hr