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

Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-05-04 00:07:57

On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik_at_[hidden]> wrote:
> 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.

With the use of Boost.BCP, it is very simple to take the parts of
boost you want and wrap it all up into a standalone project, it
handles what requirements and all.

On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik_at_[hidden]> wrote:
> 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 :

Boost.Phoenix is very powerful, and as someone else said in a
different thread, its core is only about 90 lines of code (although
that will be more once it is ported to Boost.Proto, but it will be
even vastly more powerful then).  The way it is designed is in layers
(see its documentation
www.boost.org/doc/libs/release/libs/spirit/phoenix/ , it has a whole
picture and all, nice pretty examples), and any part only relies on
pieces below it, it does not rely on any higher part, nor on any part
on the same level, and yet they all inter-operate wonderfully.  Caster
could be such a part on a layer.  And as stated, using Boost.BCP, you
can rip out the libraries it needs, then you can manually trim them
down (or another script) if you did not want to include all of Phoenix
for whatever reason.

On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik_at_[hidden]> wrote:
> (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.

Boost.Phoenix internals are also *very* small, just some parts of it
are bigger then others, all depends on the functionality you need.
The new version currently being made will be a bit bigger as its base
since it will use Boost.Proto as the metafunction handler, but it will
get a even more power by this move.

On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik_at_[hidden]> wrote:
> I would like to investigate your suggestion further ... perhaps I can
> exchange emails with you offline on this topic to orient myself in the right
> direction.

I am not the right person for this, just a user of Boost.Phoenix
(well, I have made a few customized parts for my own use, but still,
just a user), Joel De Guzman is, but he is *busy*.  It is always best
to talk about these things in the public list anyway as others can
learn from it as well.  If you wish we can talk privately, but
publicly is always better.