on Fri Feb 27 2009, Rogier van Dalen <rogiervd-AT-gmail.com> wrote:
Two alternative spellings for merged(rng1, rng2) have been suggested.
1) (Thorsten) rng1 && rng2 | merged which I think is equivalent to rng1 && (rng2 | merged) It may be possible and useful to extend this to rng1 && rng2 && rng3 | merged I personally find the interaction between operator precedence and semantics scary, but maybe others feel different.
It breaks down once there's any interesting chaining: (r1 | f1 | f2) && (r2 | f3 | f4) && (r4 | f5 | f6) | merged is no better than merge(r1|f1|f2, r2|f3|f4, r4|f5|f6) I don't think that sort of range argument packing makes any sense at all unless they have the same number of elements, in which case write zip(r1,r2,r3)
2) (Giovanni) rng1 ^merged^ rng2 which may be abuse, but it's nice. In the case of merged, rng1^merged^ rng2 ^merged^ rng3 would actually work. I'm not sure this works for all imaginable lazy range adaptors (zip?).
There appears to be a blind obsession with syntactic consistency at work here. Why else would we be groping about for infix ways to express such an operation? -- Dave Abrahams BoostPro Computing http://www.boostpro.com