I think your statement isn't only confusing to the parser, but to humans as well. The coding convention for infix operators (like * + - and / ) is to have symmetric spaces around it. Note that both those solutions work:
perl -e 'print map $_-1, 1;' and perl -e 'print map $_ - 1, 1;'
If it had been another operator, like / I suppose you wouldn't have written it on one side: $a / $b looks ok, so does $a/$b but $a /$b looks weird. So even for humans, your code looks like $_ followed by negative one.
Edit: as far as I'm concerned though, a good coding convention would not to use the map EXPR, LIST syntax unless EXPR is a single element (ex chr or /regex/), or even never use it, as the map BLOCK LIST is less confusing.
| [reply]
[d/l]
[select] |
I started to save one space between - or + and a number, if a number is small, and my intention was - readability (not too much spaces, nor too less spaces). But of course when both operands are larger or variables, then I still use symmetric spaces.
And it's difficult to understand an operator as unary, if you have read one more operand in left side of an expression. DWIM doesn't work.
But ok, thanks for suggestions.
| [reply] |
as already said in the thread you mentioned, you need to disambiguate your statement
perl -e "print map +$_ -1, 1;"
0
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply]
[d/l] |
Suddenly I found similar error with print:
use warnings;
use strict;
my $A = 0;
print $A +1 == 0 ? "A\n" : "B\n";
Can't use string ("0") as a symbol ref while "strict refs" in use at <
+...> line 5.
| [reply]
[d/l]
[select] |
Well, I said I found your first case confusing, I think this one is worse, it took me far too much time to understand what you meant to do. But the main difference is that the previous example at least was a plain old syntax error, caught at compile time. This one is valid syntax:
use strict;
use warnings;
open my $A, '>', 'out.txt';
print $A -1 == 0 ? "A\n" : "B\n";
This makes it even trickier as it might be seen too late. And this means you can't say that you can guess that an operator is not unary when there is a scalar on its left, because perl actually allows this kind of constructs.
BTW, since the ternary operator makes your example even more confusing (I find its priority obvious but non intuitive, which means I get it right but need to think about it), it can be reduced to:
print $A +1;
Edit: reduced even further from $A +1 +2 to $A +1 | [reply]
[d/l]
[select] |
| [reply] |