any interest in Boost Unification and Backtracking library (UBL)?
Hi, all, Unification and backtracking are the two key concepts of Prolog language. Prolog language is one of the preferred ways to develop "intelligent" software. I am wondering how many people here are interested in a Boost Unification and Backtracking Library (UBL). UBL will implement the unification and backtracking feature with the help of both preprocessor meta-programming (Boost Preprocessor library) and template meta-programming (MPL). With UBL, you will define Prolog-like predicates right inside your C++ code. ========== Why do we need it? =========================== 1. a C++ and Prolog combined solution may not be convenient. You need to write a lot of wrapper code to allow bi-directional communications between Prolog code and C++ code. Standard Prolog is not an Object Oriented Programming Language. As such, you need to write even more code to allow Prolog to access C++ class instances. Worse yet, each prolog implementation has its own way to interface with foreign languages. So your wrapper code most likely would not be portable to other Prolog implementations. 2. Unlike C++, Prolog is not strong-typed. Folks in the C++ land too long may not like anything that is not strong-typed. 3. C++ is a multi-paradigm language. At beginning, it was procedure oriented. Then it's object oriented. During the past few years, functional oriented programming in C++ and even aspect oriented programming in C++ become hot topics and real possibility. Now why don't we give C++ a logic programming flavor? 4. UBL allows the programmer to switch back and forth among the multi-paradigm seamlessly, therefore make it easier to combine the right features of each paradigm to solve a given problem. Better yet, you do not need to lean a new language (Prolog). =========== Is UBL feasible?=================== The short answer is yes. I already have the prototype up and running in VC++ 7.1. The 8-queen problem takes less than 28 seconds on my Athlon 2200+ to find all answers. The prototype does have its fair share of shortcomings: 1. template based metaprogramming in general, and the prototype of UBL in particular, takes too long to compile any non-trivial code. Or may not be able to compile at all. 2. syntax wise UBL predicates are not as straight-forward or visually appealing as the equivalent predicates in Prolog. Here is a predicate in UBL: BOOST_UBL_PREDICATE_2_( is_grandfather_of, Person, Person ) { BOOST_UBL_VARIABLES_3 ( Person, X , Person, Y , Person, Z ); typedef clause< LHS<X, Y> , is_father_of< X, Z > , is_father_of< Z, Y >
type; };
Here is the equivalent predicates in Prolog: is_grandfather_of(X, Y) :- is_father_of(X, Z), is_father_of( Z, Y). 3. In my plan, the Lambda library will provide the "fast-lane" between UBL and your C++ instances, member functions and member variables. Of course, that is not done yet.
"G. Wang" <visionsoft@hotmail.com> writes:
Hi, all,
Unification and backtracking are the two key concepts of Prolog language. Prolog language is one of the preferred ways to develop "intelligent" software.
I am wondering how many people here are interested in a Boost Unification and Backtracking Library (UBL). UBL will implement the unification and backtracking feature with the help of both preprocessor meta-programming (Boost Preprocessor library) and template meta-programming (MPL). With UBL, you will define Prolog-like predicates right inside your C++ code.
I'm interested. My first question would be, "what kinds of real problems can I solve better/more easily/more expressively with UBL than with approaches we already have available?" That's the test that FC++ wasn't able to pass convincingly in its review. It provided a new, interesting programming paradigm, but we couldn't figure out why any C++ programmer would find it indispensable. How is UBL different? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I'm interested. My first question would be, "what kinds of real problems can I solve better/more easily/more expressively with UBL than with approaches we already have available?" That's the test that
UBL allows you to write Prolog-like code directly inside C++. The current Prolog is modeled directly to the Prolog standard. So IMHO your question is equivalent to "what kind of real problems can I solve better/more easily/more expressively with Prolog than with approaches we already have available in C++?" Prolog is the preferred language in the field of AI, expert systems, business logics, etc. There are lots of discussions about why Prolog is better in those areas than traditional procedure-oriented or object-oriented languages. I don't think that I can cover the reasons in just a few paragraph.
G. Wang wrote:
I'm interested. My first question would be, "what kinds of real problems can I solve better/more easily/more expressively with UBL than with approaches we already have available?" That's the test that
UBL allows you to write Prolog-like code directly inside C++. The current Prolog is modeled directly to the Prolog standard. So IMHO your question is equivalent to
"what kind of real problems can I solve better/more easily/more expressively with Prolog than with approaches we already have available in C++?"
Prolog is the preferred language in the field of AI, expert systems, business logics, etc. There are lots of discussions about why Prolog is better in those areas than traditional procedure-oriented or object-oriented languages. I don't think that I can cover the reasons in just a few paragraph.
There's another question, too. Even if Prolog is better for some task, why would one prefer prolog-like template metaprogramming library? You say: .. in VC++ 7.1 The 8-queen problem takes less than 28 seconds on my Athlon 2200+ How much does it take with a real interpreter? I'm not a prolog expert, but the 'queens.pl' example which comes with gprolog runs in about 40 ms on Athlon 1700. That's 700 times faster (not counting CPU speed difference), and I'm pretty sure that g++ will be much slower than VC++ on your example. Is writing complex AI programs to be executed at compile time ever needed? - Volodya
"G. Wang" <visionsoft@hotmail.com> writes:
I'm interested. My first question would be, "what kinds of real problems can I solve better/more easily/more expressively with UBL than with approaches we already have available?" That's the test that
UBL allows you to write Prolog-like code directly inside C++. The current Prolog is modeled directly to the Prolog standard. So IMHO your question is equivalent to
"what kind of real problems can I solve better/more easily/more expressively with Prolog than with approaches we already have available in C++?"
Prolog is the preferred language in the field of AI, expert systems, business logics, etc. There are lots of discussions about why Prolog is better in those areas than traditional procedure-oriented or object-oriented languages. I don't think that I can cover the reasons in just a few paragraph.
It's not quite equivalent. You have to ask whether a _C++ Program_ would benefit enough from that paradigm to make it worthwhile to suffer the imperfect expression of it that you can achieve in a library. FC++ is modeled directly on Haskell, and I fully believe that there are real problems that one would choose to solve first in Haskell, but that didn't turn out to mean that a translation into C++ could provide compelling advantages to people already writing software in C++. Please take this question seriously. We all felt really badly about not accepting FC++ into Boost at the end of its formal review, which was a substantial emotional/time investment for its author. It was a really interesting library, but it seemed to fail a crucial utility/practicality test. I don't want something like that to happen to you. This post (http://article.gmane.org/gmane.comp.lib.boost.devel/109639) begins to give me some assurance, but it would be very helpful to hear more from you. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Hi, On Tue, Sep 14, 2004 at 09:34:11AM -0400, David Abrahams wrote:
"G. Wang" <visionsoft@hotmail.com> writes:
I'm interested. My first question would be, "what kinds of real problems can I solve better/more easily/more expressively with UBL than with approaches we already have available?" That's the test that
UBL allows you to write Prolog-like code directly inside C++. The current Prolog is modeled directly to the Prolog standard. So IMHO your question is equivalent to
"what kind of real problems can I solve better/more easily/more expressively with Prolog than with approaches we already have available in C++?"
Prolog is the preferred language in the field of AI, expert systems, business logics, etc. There are lots of discussions about why Prolog is better in those areas than traditional procedure-oriented or object-oriented languages. I don't think that I can cover the reasons in just a few paragraph.
It's not quite equivalent. You have to ask whether a _C++ Program_ would benefit enough from that paradigm to make it worthwhile to suffer the imperfect expression of it that you can achieve in a library.
FC++ is modeled directly on Haskell, and I fully believe that there are real problems that one would choose to solve first in Haskell, but that didn't turn out to mean that a translation into C++ could provide compelling advantages to people already writing software in C++.
Please take this question seriously. We all felt really badly about not accepting FC++ into Boost at the end of its formal review, which was a substantial emotional/time investment for its author. It was a really interesting library, but it seemed to fail a crucial utility/practicality test. I don't want something like that to happen to you.
I'd like to add my penny to this discussion. I'm not expert in the area of the logical programmig, but I think, that there is a crucial difference between FC++ and prolog library in the means of additional value to C++. Funcional programming is quite similar to C++ in the respect, that programmer writes "how the solution should be computed". On the other hand, in prolog the approach is different, because one writes "how the solution should look like" and the engine provides the means to achieve it. What I'm trying to tell (in very simple words) is that FC++ just allows you to write a program in different syntax, while the prolog library enables you to write it in a different way. Therefore I think, that library like this (if done properly) can be viable addition to boost. Even if it will be only in the form of unification/backtrack engine. Best regards, Pavol
=========== Is UBL feasible?===================
The short answer is yes. I already have the prototype up and running in VC++ 7.1. The 8-queen problem takes less than 28 seconds on my Athlon 2200+ to find all answers.
How much does the plain prolog version take on the same hardware? I assume the motivation for using C++ is a speed-up? And how many lines of code was the C++ version compared to the prolog one? Is there a native C or C++ solution to the 8 queen problem for comparison?
2. syntax wise UBL predicates are not as straight-forward or visually appealing as the equivalent predicates in Prolog. [Example included at bottom]
I think you will have an uphill battle to persuade people to use the library because of this. Is a compiler or macro feasible to allow me to write the prolog one liner and have it turned into the C++ equivalent. (I don't use prolog but could understand and appreciate the prolog code example.) Darren Here is a predicate in
UBL:
BOOST_UBL_PREDICATE_2_( is_grandfather_of, Person, Person ) { BOOST_UBL_VARIABLES_3 ( Person, X , Person, Y , Person, Z );
typedef clause< LHS<X, Y> , is_father_of< X, Z > , is_father_of< Z, Y >
type; };
Here is the equivalent predicates in Prolog:
is_grandfather_of(X, Y) :- is_father_of(X, Z), is_father_of( Z, Y).
participants (1)
-
Darren Cook -
David Abrahams -
G. Wang -
Pavol Droba -
Vladimir Prus