On Tuesday, January 21, 2003, at 02:38 PM, Buddha Buck wrote:
The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal...Michael Lazzaro wrote: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.
<snip>
So the apparant symmetry between <~ and ~> isn't really there.Agreed, it could be quite misleading. Personally, I'd be happier if <~ and ~> worked _only_ on objects and methods, instead of arbitrary subs... but I understand the utility of the other way.
I like <~ and ~>, but I think that it will be a common mistake to think that $a ~> b~>c~>d can be reversed to give d<~c~<b<~$a, when it can't. That, to me, is an argument against <~ and ~>, at least as currently formulated.
Of course, _I'd_ even prefer using <- and -> as the 'piping' operators, and having ~> or |> for pointy sub, because then $a->foo and $a.foo really _could_ be the same thing, 'cept for precedence. But that's not gonna happen, and _I'm_ not gonna press it. :-)
MikeL
