Re: [boost] interest in a "signal flow" library?

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-02-21 15:37:24

> <james.jones_at_[hidden]> wrote:
> >   * I'm wondering whether the choice of operators (operator(), >>=.,
> > >=) used is appropriate or whether there are better alternatives.
>
> Sounds cool. I'd probably prefer to use >> and/or << as operators, though, if for no other
> reason than they're already overloaded by iostreams, so as library users we're used to
> expecting that overload. >>= isn't similarly overloaded, so it's something of a surprise.
> operator() isn't bad either, but << or >> are better visually.
>
> I wonder if a different operator (maybe || ?) could be used to create trees? Or maybe that
> gets confusing. Your example would become:
[snip]
> because the latter implies that display2 gets input from the parenthesized sequence in
>the middle, which isn't the case (if I understood it correctly).

Yes - this brings up a downside of the current choice of using >>= and
>=, they are too similar and reading them can be confusing.  || (or |
maybe) would be a much better choice than >=, as you suggest.

The reason for using >>= is that, for something like:

source
  || (path11 >>= path12 >>= path13)
  || path2

to work, (path11 >>= path12 >>= path13) has to be evaluated right to
left in order for the expression to evaluate to path11 which needs to
connect to source.  Similarly, || needs to evaluate left to right so
that both path11 and path2 connect to source.

As far as binary operators that get evaluated right to left go, we're
pretty much stuck with different assignment operators, which would
prevent us from using >> for >>=.

Although, there could be an altogether different scheme that would
make using >> (or <<) possible :-)

Great suggestion, thanks!

Stjepan