Glad someone posted that link, or I was going to :)
Pipes and method chaining "feel" the same. They're both expressions, but with the property that you could rewrite them as what looks like a series of statements without changing the semantics (although possibly changing the efficiency). e.g.
usual_suspects.director.surname
has the same value ("Singer") as
person = usual_suspects.director
surname = person.surname
surname
They feel the same because they're both monadic (at least when the chained methods or piped processes behave in certain 'normal' ways). '.' (the method invocation operator) and '|' (the pipe operator) are monadic combinators, just like Haskell's >>= and F#'s |>. And a monadic combinator is just a generalisation of function composition.
Monads are going to become a lot more important in the next few years, as programming languages get more expressive and capable of more abstraction. LINQ in C# and VB is a great example - while it looks like they've baked in language support for lots of concepts (querying databases and XML, for data parallelism and for event-driven programming), what they've really done is recognised that those are all forms of monadic computation, baked in language support for one thing (monadic expressions), then implemented those concepts as libraries that any user could have written. (Erik Meijer and Brian Beckman on MS's Channel 9 explain this really nicely.)
I remember first running into this point with http://xahlee.org/UnixResource_dir/writ/notations.html and I'm sure Slava or somebody has pointed out that in postfix languages like Factor and Forth everything is essentially chained which very naturally leads to a function composition style. And that despite the "reverse" nature of RPN it often ends up being "forward", witness in Factor REPL actually being REPL instead of L(P(E(R))).
I've seen an interesting way to do method chaining in haskell: The '$' operator: Basically it's a low-priority right-associative binary operator that applies the function to the left to everything to the right.
Using the example from the article, one could do it as:
($) helps to avoid some parens. The (.) is more common to change functions, and closely related. ($) does not really compose functions, it is function application and right associative.
I don't think ternary expression is ugly by itself, it's only ugly if parameters themselves are chains beacuse then you're back to having a tree. Which is the fundamental problem - chaining is not good for branches, so any branches send you back to nesting. On the higher level theproblem is that you are trying to express a tree as a list - ain't going to work.
Haskel side-steps this problem in a neat way - you can take advantage of delayed evaluation and give names to both arguments of the ternary expression so each individual piece looks linear. So your "tree" is broken down line by line:
x=...
y=...
z=f?x:y
which is as neat and easy to read as a chain, but is more powerful because it can express a tree.
Once could enforce this sort of reader-friendly style by forbidding expressions in ternary operators.
Comparing a model in which the contract is 'everything is a stream of characters' to function application and composition in just about any programming language seems more than a little clueless.
"I think there's a connection. Certainly in the early days of Unix, pipes facilitated function composition on the command line. You could take an input, perform some transformation on it, and then pipe the output into another program. (...) [The mathematical approach of function composition is] exactly what I mean. (...) I think [that mathematical formalism] was right there from the start. Doug McIlroy, at least in my book, deserves the credit for pipes. He thought like a mathematician and I think he had this connection right from the start. I think of the Unix command line as a prototypical functional language."
-- from an interview with Alfred Aho, one of the creators of AWK
[+] [-] camccann|16 years ago|reply
Or you can think of it like this:
netstat_n >>= grep "tcp" >>= flip awk 5 >>= sort >>= uniq_c >>= sort_n
See also: http://okmij.org/ftp/Computation/monadic-shell.html
[+] [-] samstokes|16 years ago|reply
Pipes and method chaining "feel" the same. They're both expressions, but with the property that you could rewrite them as what looks like a series of statements without changing the semantics (although possibly changing the efficiency). e.g.
has the same value ("Singer") as and outputs the same thing (root's home directory) as They feel the same because they're both monadic (at least when the chained methods or piped processes behave in certain 'normal' ways). '.' (the method invocation operator) and '|' (the pipe operator) are monadic combinators, just like Haskell's >>= and F#'s |>. And a monadic combinator is just a generalisation of function composition.Monads are going to become a lot more important in the next few years, as programming languages get more expressive and capable of more abstraction. LINQ in C# and VB is a great example - while it looks like they've baked in language support for lots of concepts (querying databases and XML, for data parallelism and for event-driven programming), what they've really done is recognised that those are all forms of monadic computation, baked in language support for one thing (monadic expressions), then implemented those concepts as libraries that any user could have written. (Erik Meijer and Brian Beckman on MS's Channel 9 explain this really nicely.)
[+] [-] frognibble|16 years ago|reply
(-> netstat_n (grep "tcp") (awk 5) sort uniq_c sort_n print)
[+] [-] Avshalom|16 years ago|reply
[+] [-] voxcogitatio|16 years ago|reply
Using the example from the article, one could do it as:
sort -n $ uniq -n $ sort $ awk '{ print $5}' $ grep tcp $ netstat -n
I.e essentially the same but in reverse order.
[+] [-] eru|16 years ago|reply
Your example would rather read something close to
(And `$ argument' at the end, if there was one.)[+] [-] DenisM|16 years ago|reply
Haskel side-steps this problem in a neat way - you can take advantage of delayed evaluation and give names to both arguments of the ternary expression so each individual piece looks linear. So your "tree" is broken down line by line:
which is as neat and easy to read as a chain, but is more powerful because it can express a tree.Once could enforce this sort of reader-friendly style by forbidding expressions in ternary operators.
[+] [-] pvg|16 years ago|reply
[+] [-] camccann|16 years ago|reply
-- from an interview with Alfred Aho, one of the creators of AWK
http://books.google.com/books?id=yB1WwURwBUQC&lpg=PT120&...