Support for the Logic paradigm in C++ (with Castor)
This library (Castor) may be of interest to the "paradigm redefining" Boost community also ... -Roshan Naik ------------------------------------------------------------ Castor is a pure C++ Library that introduces the Logic paradigm (LP) into C++. Although LP has been well explored in Computer science, it remains under utilized in main stream software development due to lack of support in popular programming languages. Among the few languages that do support it, Prolog is perhaps the most commonly known. Instead of attempting to embed a Logic interpreter or other heavy weight engine into C++, Castor integrates LP using a few simple library primitives. This unique approach allows a natural and deep integration of declarative code into the language, and also provides the flexibility of combining Logic with other paradigms natively supported by C++ such as OOP, generics etc. STL concepts like iterators ,containers and streams can also be used in declarative code. Castor is an open source library distributed under the MIT license (http://www.opensource.org/licenses/mit-license.php). It is relatively small (under 5k LOC) and can be downloaded for free from http://www.mpprogramming.com For an introductory tutorial on LP and understanding its use in C++ refer to http://www.mpprogramming.om/resources/CastorTutorial.pdf Feedback, comments and contributions are welcome.
On Feb 11, 2008 4:29 AM, Naik, Roshan <roshan.naik@hp.com> wrote:
For an introductory tutorial on LP and understanding its use in C++ refer to http://www.mpprogramming.om/resources/CastorTutorial.pdf
Try this instead (typo above): http://www.mpprogramming.com/resources/CastorTutorial.pdf
Oops. Thanks Jon. -Roshan ________________________________ From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jonathan Franklin Sent: Monday, February 11, 2008 8:28 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Support for the Logic paradigm in C++ (with Castor) On Feb 11, 2008 4:29 AM, Naik, Roshan <roshan.naik@hp.com<mailto:roshan.naik@hp.com>> wrote: For an introductory tutorial on LP and understanding its use in C++ refer to http://www.mpprogramming.om/resources/CastorTutorial.pdf Try this instead (typo above): http://www.mpprogramming.com/resources/CastorTutorial.pdf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 11 February 2008 06:29 am, Naik, Roshan wrote:
Castor is an open source library distributed under the MIT license (http://www.opensource.org/licenses/mit-license.php). It is relatively small (under 5k LOC) and can be downloaded for free from http://www.mpprogramming.com
For an introductory tutorial on LP and understanding its use in C++ refer to http://www.mpprogramming.om/resources/CastorTutorial.pdf
Feedback, comments and contributions are welcome.
I don't know anything about logic programming, and I've only gotten about 1/4 of the way through the tutorial so far, but I find it quite interesting. Thank you for the library. One criticism I have is the overloading of the logical or/and operators, which will create confusion in people reading code that uses Castor. The logical operators have very precise and well-understood meaning for any C/C++ programmer, and what Castor uses them for definitely isn't it. I know some other people have very liberal views about operator overloading, but they're just wrong :) Also, the relation class seems to be a bit nebulous, as in it seems to embody multiple ideas. It's a fact, it's a collection of facts, or maybe it's a rule too. This criticism may not be well founded though, as I said before I'm not speaking from any experience with logic programming here. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHshic5vihyNWuA4URAuDPAJ4u3LSWMJRlBwjBtKIiMfXpTBinlACeKBeT Nedcwhe7TCuzUPpyujEqdVo= =WOeF -----END PGP SIGNATURE-----
One criticism I have is the overloading of the logical or/and operators, which will create confusion in people reading code that uses Castor. The logical operators have very precise and well-understood meaning for any C/C++ programmer, and what Castor uses them for definitely isn't it. I know some other people have very liberal views about operator overloading, but they're just wrong :)
Lets put it like this: eq(x,"logical operators have very precise meaning") && eq(y, "it is well-understood meaning for any C/C++ programmer") && eq(z, "what Castor uses them for definitely isn't it") "Logic"ally you stated : x && y && z. These logical operators are used logically. :)
Also, the relation class seems to be a bit nebulous, as in it seems to embody multiple ideas. It's a fact, it's a collection of facts, or maybe it's a rule too. This criticism may not be well founded though, as I said before I'm not speaking from any experience with logic programming here.
In LP the term "relation" is essentially "some set of information". Wether the information is made up of facts, rules, facts+rules or is empty or infinite it doesn't matter. The class relation in Castor is smiply a way to carry this information around and put it to use.
On Tuesday 12 February 2008 21:19, Naik, Roshan wrote:
One criticism I have is the overloading of the logical or/and operators, which will create confusion in people reading code that uses Castor. The logical operators have very precise and well-understood meaning for any C/C++ programmer, and what Castor uses them for definitely isn't it. I know some other people have very liberal views about operator overloading, but they're just wrong :)
Lets put it like this:
eq(x,"logical operators have very precise meaning") && eq(y, "it is well-understood meaning for any C/C++ programmer") && eq(z, "what Castor uses them for definitely isn't it")
"Logic"ally you stated : x && y && z. These logical operators are used logically. :)
You're kind of making my point as I'm sure I have no idea what you're talking about. I realize your operations correspond in a broad sense to types of logical or/and operations. My position is more like: if the operation doesn't return a bool, it shouldn't even be in the realm of consideration for overloading operator|| or operator&&.
Also, the relation class seems to be a bit nebulous, as in it seems to embody multiple ideas. It's a fact, it's a collection of facts, or maybe it's a rule too. This criticism may not be well founded though, as I said before I'm not speaking from any experience with logic programming here.
In LP the term "relation" is essentially "some set of information". Wether the information is made up of facts, rules, facts+rules or is empty or infinite it doesn't matter. The class relation in Castor is smiply a way to carry this information around and put it to use.
Ok, but there are no more specialized types corresponding to more specific ideas. It's sort of like building a program with nothing but one class called "object". So, you get into this position where you're doing things like having the dereferencing operator return a different result each time it's called, because maybe the relation is really a collection of relations, and you want to extract them individually somehow. It seems like you would be better off having a well defined container class that holds fact objects, for example. -- Frank
On Tuesday 12 February 2008 21:58, Frank Mori Hess wrote:
My position is more like: if the operation doesn't return a bool, it shouldn't even be in the realm of consideration for overloading operator|| or operator&&.
After a little more reflection, that's a little too strong a statement and not quite right, but you get the idea? -- Frank
types of logical or/and operations. My position is more like: if the operation doesn't return a bool, it shouldn't even be in the realm of consideration for overloading operator|| or operator&&.
does return bool .. when (lazy) evaluation is triggered.
It's sort of like building a program with nothing but one class called "object".
Relations in LP loosely correspond to functions in the imperative paradigm and not objects.
It seems like you would be better off having a well defined container class that holds fact objects, for example.
I encourage you to pursue the list<facts> approach to see the pitfalls. But before you implement LP ... understand LP. Solve a few problems using any LP system, Castor or whatever. Your concerns are natural for an OO expert (and beginner in LP) who is wondering why it is this the way it is. -Roshan
Frank Mori Hess escreveu:
eq(x,"logical operators have very precise meaning") && eq(y, "it is well-understood meaning for any C/C++ programmer") && eq(z, "what Castor uses them for definitely isn't it")
"Logic"ally you stated : x && y && z. These logical operators are used logically. :)
You're kind of making my point as I'm sure I have no idea what you're talking about. I realize your operations correspond in a broad sense to types of logical or/and operations. My position is more like: if the operation doesn't return a bool, it shouldn't even be in the realm of consideration for overloading operator|| or operator&&.
Spirit is precedent for this kind of usage. And Spirit works just fine. In practice, a programmer elaborating a parser using expression templates from Spirit doesn't get confused. Unless of course he is a novice. Is this a novice-level library? -- P.
participants (4)
-
Frank Mori Hess -
Frank Mori Hess -
Jonathan Franklin -
Naik, Roshan -
Pedro Lamarão -
shunsuke