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

Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-03 19:05:37

----- Original Message ----- 
From: "Roshan" <roshan_naik_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 03, 2010 11:20 PM
Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?

> 
> On Sun, 02 May 2010 20:40:39 -0600, OvermindDL1 <overminddl1_at_[hidden]>  
> wrote:
> 
>> However, I notice a *lot* of overlap with Boost.Phoenix, it kind of
>> seems like a continuation layer on top of Boost.Phoenix, and it
>> probably could in fact be implement as a layer of Boost.Phoenix
>> (Boost.Phoenix is made up of layers of functionality, and a logic
>> layer makes sense).  Boost.Phoenix is a lazy evaluation framework for
>> C++.  When it is finished being ported to Boost.Proto for
>> Boost.Phoenix 3,
> 
> 
>> I think a Caster-style Logic layer would make a lot
>> of sense, and would allow it to blend far more easily into the rest of
>> boost while getting all the functionality of Boost.Phoenix (including
>> the calling style fixes that Boost.Phoenix uses, val/ref's and such),
>> along with pure lazy *type* inference too (which Caster does not do at
>> all, not a major limitation, but one that could cause more code to be
>> created at times then necessary), which would solve the whole
>> list/vector thing the tutorial talks about (along with supporting any
>> generic container transparently).
>>
>> Have you thought about this?
> 
> Nope! I have restrained from introducing any cross library dependencies in  
> an effort to keep it a standalone library. I am very keen on ensuring  
> Castor continues to be distributable & usable as a standalone library even  
> if included into Boost.
> 
> However your suggestion interests me. From what I read, it seems that it  
> might be possible to "peel off" just the necessary amount of Phoenix  
> without dragging in all of Phoenix or rest of Boost. This sounds appealing  
> to me since I want to ensure :
> 
> (Benefits to end users + Benefits of code reduction in Castor's  
> internals)  > disadvantages of depending on another library (Phoenix)
> 
> Often these secondary libraries are too big (mcuh bigger than all of  
> Castor) and in turn depend on other (Boost) libraries. Castor 1.0 is a  
> really small library (under 5k LOC).
> The simple lambda support in Castor 1.0 totals to about 300 lines of  
> code... compare that to relying on the "all powerful" boost.lambda which  
> is about 14k LOC. Wasn't worth it.

Hi,

this is no the first time some one want to introduce a library in Boost but don't want to use nothing of Boost; even if the abstraction already exist in Boost.
Whether a library I use is about 1KLOC or 100KLOC it is not important to me, if the service the library provides is what I need.

What kind of users do you want to preserv with a standalone library that will not use your library if it depends on Boost?

Best,
Vicente