Re: [boost] [review] Dataflow Library

Subject: Re: [boost] [review] Dataflow Library
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-04 09:51:42

on Wed Sep 03 2008, "Stjepan Rajko" <stipe-AT-asu.edu> wrote:

> On Wed, Sep 3, 2008 at 5:08 PM, David Abrahams <dave_at_[hidden]> wrote:
>>
>> I was reading other review commentary when it occurred to me that
>> Boost.Accumulators is also implementing a dataflow system.  I would like
>> to know if Stjepan considered Boost.Accumulators and whether his library
>> could build on some of that work.
>>
>
> I have looked at Boost.Accumulators, and really like it's dataflow
> characteristics, especially the way it deals with dependencies.  As
> far as building on it, at the moment the Dataflow library is in it's
> entirety focused on connecting components at run-time, and (unless I
> am mistaken), the dataflow connections in a Boost.Accumulators
> accumulator_set are all determined at compile time.  

I believe that is correct, except for "dropping" of accumulators, which
adds a runtime component.

I am not really an expert on what you'd use such a library for It seems
like compile-time configurability is of much greater interest in general
for problems you'd approach with dataflow, especially if you are using a
DSEL to describe the system.  In other words, when you actually *need*
runtime configurability you'd probably want a graphical front-end or
something, and the syntax of making connections in C++ wouldn't matter
much.  Am I missign something?

> So far, my only adventure into compile-time connections was a brief
> component composition study for Dataflow.Signals, where I verified
> that one could take a chain of components (what would at run-time be
> connected using the syntax, e.g., c1 >>= c2 >>= c3) and turn it into a
> single component that performs the same operation, but with the
> intermediate calls being connected at compile-time.  By that I mean
> that, e.g., where in the run-time chain c1 would send a signal using
> Boost.Signals to c2, in the compile-time composition c1 calls c2
> directly (with the call possibly being optimized out by the compiler).
>
> At some point (and that might be far into the future), I would like to
> extend the Dataflow library to the compile-time realm.  At that point,
> it will need a way for dataflow networks to be specified at compile
> time, and so far my thoughts on possible ways of doing that are:
>  * using Proto expression trees
>  * using, factoring out, or mimicking the way Boost.Accumulators does it
>  * using a compile-time metagraph library, like the one suggested by
> Gordon Woodhull:
> http://archives.free.net.ph/message/20080706.145113.313c713e.en.html

Yeah, I couldn't really get a grip on what Gordon was describing, so I
thought I'd wait for his "soon, soon" which AFAIK hasn't happened yet
:-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com