From: Braddock <braddock@braddock.com> Subject: Re: [boost] interest in a "signal flow" library?

However, adopting a functional style is one thing. But creating a new syntax which constrains you to that style, appears less expressive than the C++ language itself, and will undoubtedly be more difficult to maintain, is an act that requires considerable justification.

I would have a legitimate need for your syntax if, for example, the different functions executed in parallel threads, or were queued to specific worker threads, if I could somehow otherwise control and schedule the execution of the invoked functions, or traverse the call graph. This could bring it closer to a "pipes and filters", LabView, or Petri Net design, but all are very different than straight signal wiring of serial processes.

Adding functionality that relates to the network as a whole (like traversing the call graph) would indeed be a significant leap in the usability of the library. It might take a while for me to find a good way of doing that, but I'll definitelly try something. The threading idea is great - I think I'll be shifting my focus to using the thread_safe_signals and trying to tackle some of those possibilities. Thanks, Stjepan