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

[<gon...@gm...>]

Dear Markus, David et al,

It's great to find growing support and interest on a .NET interface.
I've set up a management page for my current source code at
http://articaserv.ath.cx/XSBDotNet. The SVN code can be offloaded from
the repository using any SVN client at
svn://articaserv.ath.cx/XSBDotNet. I can also make a binary release
available to those who just want to try it out "out-of-the-box". I'll
definitely work on proper documentation and usually I try to use a
unit testing methodology.

So far, all the tests I've made have been successful, but there are
bound to be issues, especially where the multithreaded engine is
concerned. I'll post one of these issues in the following e-mail.
Right now, I'll just post two small code snippets of what XSBDotNet
offers so far for the .NET programmer (in C#):

        static void Main(string[] args)
        {
            XSBPrologEngine engine =3D XSBPrologEngine.Instance;
            engine.Command("consult(basics).");
            QueryHandle handle =3D engine.Query("member(X,[1,2,3]).");
            foreach (PrologAnswer answer in handle)
            {
                PrologTerm groundedTerm =3D answer.QueryTerm;
                System.Console.Out.WriteLine(
                    "Answer: {0}",
                    groundedTerm.GetFunctorArgument(1).GetIntValue()
                );
            }
        }

As you can see, the PrologEngine instance is a singleton, since for
now you can only call xsb_init once. There is support for commands and
queries, supporting both strings and PrologTerms built from C#. The
result from a query is in fact an enumeration of all the possible
answers, containing both the terms from reg1 and reg2. At each step of
the foreach cycle, a backtrack is issued and a new answer, if any, is
produced. It is also possible to terminate the enumeration at any
given time by just closing the handle.

Now a small example of defining a C# method to run as a XSB predicate:

        static bool HelloFromDotNet(PrologTerm[] arguments)
        {
            if (arguments.Length !=3D 0)
            {
                arguments[0].BindAtom("hello");
                return true;
            }
            else return false;
        }

        static void Main(string[] args)
        {
            XSBPrologEngine engine =3D XSBPrologEngine.Instance;
            engine.RegisterManagedPredicate("hellodotnet", HelloFromDotNet)=
;
            QueryHandle hello =3D engine.Query("managed(hellodotnet(X)).");
            foreach (PrologAnswer answer in hello)
            {
                System.Console.Out.WriteLine(
                    "Echo: {0}",
                    answer.QueryTerm.GetFunctorArgument(1).GetAtomName()
                );
            }
        }

As you see, the only requirement for the C# method is that it returns
bool and receives an array of PrologTerm representing the arguments of
the goal. Then, it's only necessary to register the function with the
XSBPrologEngine, passing it the name of the Prolog predicate being
implemented by the function.

engine.RegisterManagedPredicate("hellodotnet", HelloFromDotNet);

After that, the method can be called from XSB by use of the managed/1
predicate, which receives a goal to execute inside .NET framework:

QueryHandle hello =3D engine.Query("managed(hellodotnet(X)).");

It is of course admissible to "inline" the predicate with something like:

hellodotnet(X) :- managed(hellodotnet(X)).

for greater declarativity (there are some other solutions to go around
this, but I aimed for implementation simplicity first).

That's it for now.

Best regards,

Gon=E7alo


On 1/17/07, David Warren <wa...@cs...> wrote:
> Markus and Gon=E7alo (et al.),
>
> I really appreciate your willingness to contribute to the XSB effort.
> I have essentially no knowledge of .NET, so we'll have to depend on
> you two.  And it's good that there are two of you with knowledge and
> interest to determine the best interface.
>
> One important thing to keep in mind is that XSB, and the environments
> in which it runs, are both evolving.  So code that works today may not
> work tomorrow.  The best solution is to make the code transparent and
> to incorporate tests of it somehow into the XSB testsuite.  Then
> changes that affect your code can be caught early and they (or your
> code) can be fixed before problems accumulate.  We will have to think
> about how to include your subsystem in the XSB system.  We don't like
> to distribute broken code, which means we will need to find a way to
> ensure that it stays up-to-date.
>
> Of course, good documentation is also a requirement :-).
>
> Good luck and keep us posted on your progress,
> -David
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Xsb-development mailing list
> Xsb...@li...
> https://lists.sourceforge.net/lists/listinfo/xsb-development
>