Michael Lazzaro writes: > And it provides a very visual way to define any pipe-like algorithm, in > either direction: > > $in -> lex -> parse -> codify -> optimize -> $out; # L2R > > $out <- optimize <- codify <- parse <- lex <- $in; # R2L > > It's clear, from looking at either of those, that they represent data > pipes. Both are even clearer than the equiv: > > $out = $in.lex.parse.codify.optimize; > > Whether you would code a pipeline as L2R or R2L depends on the specific > algorithm you're representing, and is purely a matter of taste... > you'd probably use R2L in the same places as you use C<map>-like > chaining in Perl5. I can't begin to justify why one should be superior > to the other, and would certainly use them both. >
This explanation of (and rationale for) a "post-invocant" underpinning for l2r/r2l pipe-lining was wonderfully clear. I've also found that newish perl programmers frequently find C<map> and friends to be confusing, particularly when they are traveling in a pack (not to speak of an C<unpack>). One question: How does this approach to building a pipe-lining syntax square with the "alternative spelling of the assignment operator" feature that's been discussed elsewhere in this thread? It's not immediately obvious to me how the post-/pre-invocant operation "becomes" an assignment at the end of the chain. In other words, are the first two code fragments above really equivalent to the third? Kwin
