Larry Wall wrote: > So you can say > > for =$*IN {...} > for =$*ARGS {...} > for =<foo.c> {...} > for =<foo.c foo.h> {...} > for =«$foo.c $foo.h» {...} > for =['foo.c', 'foo.h'] {...} > for =['.myrc', @*ARGS] {...} > for =@handlelist {...} > for =<> {...} > > The simplicity is nice, but the visual message is, well, icky. It might be salvageable by having the ='s balance, yielding: for =$*IN= {...} for =$*ARGS= {...} for =<foo.c>= {...} for =<foo.c foo.h>= {...} for =«$foo.c $foo.h»= {...} for =['foo.c', 'foo.h']= {...} for =['.myrc', @*ARGS]= {...} for =@handlelist= {...} for =<>= {...} That looks better. Might even make the trailing = mean something useful like "auto-chomp". >And I don't think it'll be visually confusing to people who put spaces >on both sides of their assignment operators. > > But those of us who often use the horizontal ws to break up the terms on a line will moderately often not put spaces around our assignments and less thans. Okay, this rant is more about the \s<\s than \s=\s. To me, it is easier to understand the grouping of line 1 than line 2 below: if( $a<$b && $c<$d ) {...} if( $a < $b && $c < $d ) {...} In line2, my mind has to stop and ask: is that "($a < $b) && ($c < $d)", or "$a < ($b && $c) < $d". It quickly comes to the right answer, but the question never comes up in the first line. If I wanted to use more parens for clarity, I'd use LISP. -- Rod Adams