Smylers wrote:
Michael Lazzaro wrote:
The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal...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.
Yes; that is nice. I'm just not convinced that it's sufficiently nice to require adding yet another way of passing data around to the language. I'm happy enough with the asymmetry that occurs just having the arrows to indicate 'reverse flow' data.
Perl 5 has two different code calling conventions: object oriented method calls, and procedural subroutine calls.
OO method calls are L2R already:
$object.method1().method2().method3().method4();
Procedural subroutine calls are R2L already:
sub4 sub3 sub2 sub1 $variable;
But there is no way to do OO method calls R2L, and there is no way to do procedural subroutine calls L2R.
Damian's ~> and <~ proposal fills in this gap:
method4 <~ method3 <~ method2 <~ method1 <~ $Xbject;
$variable ~> sub1 ~> sub2 ~> sub3 ~> sub4;
To the best of my knowledge, the following two WILL NOT WORK:
sub4 <~ sub3 <~ sub2 <~ sub1 <~ $variable;
$Xbject ~> method1 ~> method2 ~> method3 ~> method4
The first one tries to invoke the sub1 method of $variable, while the second tries to call the method1 function with $object as an argument. If either of these works, it's either coincidence or careful planning.
So the apparant symmetry between <~ and ~> isn't really there.
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.
