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-02 22:40:39

On Thu, Apr 29, 2010 at 1:12 AM, Roshan Naik <roshan_naik_at_[hidden]> wrote:
> Based on suggestions from some Boost community experts, I would like to
> gauge interest to see if there is broader interest for including the Castor
> library into Boost. In short, Castor's aim is to foster multiparadigm
> programming in C++ by supporting techniques from the Logic Paradigm. See
> below for a longer description.
>
>
> ==============
> Description:
> ==============
>
> Logic Paradigm (LP) is a general purpose declarative programming paradigm.
> It focuses on "what" to compute and not "how" to compute. Although LP has
> been well explored in Computer Science as a fundamental computational model,
> it remains unavailable for main stream software development due to lack of
> support in popular programming languages. Prolog is perhaps the most
> commonly known language among those that support LP. Castor takes a pure
> library approach (i.e. without language extensions) for introducing LP to
> C++.
>
> Instead of providing a Logic interpreter or evaluation engine in library
> form, Castor provides a few simple library primitives on which LP techniques
> can be supported. This approach allows a natural and deep integration of
> declarative code into the language and also provides the flexibility of
> freely combining Logic with the other paradigms such as OO, generics,
> functional etc. STL concepts like iterators, containers and streams can also
> be used in declarative code.
>
> For an introductory tutorial on LP in C++ and Castor please refer to
> http://mpprogramming.com/downloads/betaTutorial.pdf.
>
> Castor is intended to be a free standing library that depends only on the
> standard C++ library. It does not depend on Boost or other libraries. It is
> a pure header library.
>
> ==============
> Current State:
> ==============
> A stable 1.0 version has been available since 2008 on
> www.mpprogramming.com/cpp under the MIT license. Work on version 1.1 is in
> progress and an early beta is now available. Current efforts are directed
> largely towards making Castor a richer "standard library" for working with
> LP in C++.
>
> Castor was not originally targeted for Boost but more recently I have been
> giving it more serious consideration regarding inclusion into Boost. At the
> upcoming BoostCon 2010 I will be presenting 'Logic Paradigm for C++'. If
> there is interest, my thought is that feedback from the Boost
> review/submission process and modifications to satisfy other Boost
> requirements/guidelines will perhaps yield a 1.2 version that will become
> the real Boost candidate. Any help in this space will be much appreciated.
>
>
> ==================
> Links for  Castor - v1.1 beta (ported to Gcc 4.4.1 and VC++ 2008) :
> ==================
>
> Â  Â  Library+docs: http://mpprogramming.com/downloads/prebeta-1.1.zip
>
> Individually downloadable documentation:
> Â  Â  Tutorial: http://mpprogramming.com/downloads/betaTutorial.pdf
> Â  Â  Reference Manual: http://mpprogramming.com/downloads/betaRefManual.pdf
>
> Â  Â  Design doc: http://mpprogramming.com/downloads/betaDesignDoc.pdf

Ignoring the rest of the comments in this thread for now, I have some comments.

I like the whole design of it, some limitations seem overcome by some
Boost libraries though.

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?

Overall though I am quite impressed, I could see uses for this to
simplify scaffolding in many ways, just to start with.