Re: [Boost-users] Support for the Logic paradigm in C++ ( with Castor )

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-02-12 21:58:19

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