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
Thread Previous
|
Thread Next