Maybe not a good thing to say on the Drools mailinglist, but maybe there
are alternatives that require less work. Since Prolog is backward
chaining with integrated search and Drools is forward chaining and has
no search support, I think moving from the former to the latter might be
a rather big change.
Alternatives to consider are Prolog interpreters written in Java
(JIProlog, tuProlog, etc): their performance might be less than Prolog,
but don't forget Drools is also an interpreter; or maybe better use a
compiler that compiles your existing Prolog source code to executable
Java classes (JProlog, etc) or bytecode.
Peter
Marcelo Tallis wrote:
We were using prolog to implement the inference support for our
applications. Now we are looking at switching to drools because we cannot
bare the overhead of translating between java and prolog the representation
of every data element that we pass to prolog. For example, integer numbers
in java are represented differently than in prolog and their representation
needed to be translated back and forth across the java / prolog interface.
Drools seems to handle java objects in its primitive representation (good!).
However, we don't know how objects are represented in WorkingMemory.
Question:
-------------
Is the WorkingMemory keeping its own parallel COPY of the asserted objects
or it is only keeping REFERENCES to the actual objects? If the WM is copying
(or creating its own representation) of the asserted objects then the drools
alternative might not be as attractive as we thought.
Thanks,
Marcelo
