has there been proposals/research on having non linear / branching pipe syntax ? a |1 b | c | d, |1 e aka piping a to both b,c,d and e branches ?
[deleted]
For the Love of Pipes
41–50 of 323 posts
Re: For the Love of Pipes
#42has there been proposals/research on having non linear / branching pipe syntax ? a |1 b | c | d, |1 e aka piping a to both b,c,d and e branches ?
Smalltalk's "method cascading" (the `;` operator) did roughly that. I don't think you're forking an entire sequence of methods though, it just allows performing operations on the same root object e.g.
a foo
; bar
; baz
The ability to fork iterators (which may be the semantics you're actually interested in) also exists in some languages e.g. Python (itertools.tee) or Rust (some iterators are clonable)
Re: For the Love of Pipes
#43Earlier quoted context omitted.
Chmod +x /dev/null (havent tried above, not sure I recommend that you do)
Well you can't read either from /dev/null, and I don't think that's just a question of permissions. I'm pretty sure it's impossible to get /dev/null to behave like an executable.
You can read from /dev/null—it just behaves as a zero-length file, immediately returning EOF.
This makes /dev/null a valid source file in many languages, C included.
Re: For the Love of Pipes
#44Why isn't the pipe a construct that has caught on in 'proper' languages?
[deleted]
Re: For the Love of Pipes
#45Earlier quoted context omitted.
Chmod +x /dev/null (havent tried above, not sure I recommend that you do)
Well you can't read either from /dev/null, and I don't think that's just a question of permissions. I'm pretty sure it's impossible to get /dev/null to behave like an executable.
Interesting question.
You could write a executable that accepts piped input and throws it away.
When would it exit though? Would it exit successfully at the end of the input stream? That sounds sensible.
That would be behaving like an executable wouldn't it?
Re: For the Love of Pipes
#46Re: For the Love of Pipes
#47has there been proposals/research on having non linear / branching pipe syntax ? a |1 b | c | d, |1 e aka piping a to both b,c,d and e branches ?
tee ?
edit:
a | tee >(b | c | d) | e
Re: For the Love of Pipes
#48For an alternative view, don't forget to read the section on Pipes of The Unix-Haters Handbook : http://web.mit.edu/~simsong/www/ugh.pdf (page 198)
Or p160 by internal numbering.
Re: For the Love of Pipes
#49Why isn't the pipe a construct that has caught on in 'proper' languages?
There is a tradition in C++ of overloading operator| for pipelining range operations. Your mileage may vary.
Re: For the Love of Pipes
#50Earlier quoted context omitted.
OCaml has had the pipe operator |> since 4.01 [0] It actually somewhat changes the way you write code, because it enables chaining of calls. It's worth noting there's nothing preventing this being done before the pipe operator using function calls. x |> f |> g is by definition the same as (g (f x)). In non-performance-sensitive code, I've found that what would be quite a complicated monolithic function in an imperati…
IMO the really useful part of pipes is less the operator and more the lazy, streaming, concurrent processing model. So lazy collections / iterators, and HoFs working on those. The pipe operator itself is mostly a way to denote the composition in reading order (left to right instead of right to left / inside to outside), which is convenient for readability but not exactly world-breaking.
What you're describing sounds a lot like reactiveX - http://reactivex.io/
I only have experience using RxJS, but it's incredibly powerful.