Re: [boost] [castor] Interest in Logic Paradigm for C++ ?

Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
From: Roshan (roshan_naik_at_[hidden])
Date: 2010-05-08 12:59:16

On Fri, 07 May 2010 08:10:49 -0600, vicente.botet  
<vicente.botet_at_[hidden]> wrote:

> Is the efficient alternative based on co-routines?

Yes, thats definitely one way.

>> This style leads to "open ended" relations. Anybody can inject clauses
>> into child or father...dangerous. then you need protection mechanisms.
>> The current style ensures "closed" relations by default... which is
>> similar to C++ functions being "closed".
>
> A dynamic relation  is not closed neither or is it?
>

It is not closed by default since it has to be modifiable at runtime.
But you can close it easily if you don't want others to mess with it as  
show here.

Instead of :

Disjunctions foo;
foo+= ..;

You would write:

relation foo(..) {
    Disjunctions res;
    res+= ...;
    res+= ...;
    return res;
}

Now only foo's author has the ability to mess with it.
The default way of doing business with Castor is to keep things closed.

> Definitely I need to read completly  the documentation. Do you have some  
> tutorials on which we see how this integration is achieved?

Here is a simple one involving polymorphic member relations:

template<class T>
struct Collection {  // interface
       virtual relation item(lref<T> i) = 0;
}

template<class T>
struct BinaryTree: Collection<T> {
     virtual relation item(lref<T> i);
};

It is easy to visualize how member relations can also be templatized like  
regular member functions.
You can obviously use patterns like CRTP or any other involving  
inheritance and/or generics.
Too many to mention... but I hope you get the idea. You are able to carry  
those designs naturally forward.

>
> I like this. Is iterable part of the library or an alternative design?

Not yet part of Castor. At the moment its just a thought in my head. If  
you write one let me
know, we could add it in.

> Can you point me to the different implementation that is efficient?

The imperative implementation that we just discussed is likely be more  
efficient
in this case. There will be many ways of doing things depending on what  
relations
you already have handy.

>> No need for inheritance either.
>
> Grat. I just writo : relarion as I had not found the definition of the  
> Concept behind relation on the tutorial? is it any functions returning  
> bool and having lref parameters?
>

Its briefly mentioned in the tutorial under section on "type relation".
It is similar to function<bool(void)>. Other than it will take only
function objects (not ordinary functions)
Reference manual and design doc also have it.

> Wow, are coroutines part of the library also? or is just an alternatives  
> design?
> Could you point to a complete example on the documentation?

They are part of the current 1.1 pre-beta (but not 1.0). Look under  
section 3 in the tutorial.
Also documented in the reference manual.

> If all the utilities you have given are already on the library it is  
> time I read completly the documentation.

:-)

-Roshan