I just send the following letter to p5p:
This is a plea to remove the 'print (...) interpreted as function'
warning.
Let's look at the rational for this warning. It's to warn programmers
that if they write:
print (3 + 4) * 2;
Perl adds 3 and 4, calls print with the result as argument, and multip
+lies
the result of the print with 2. Fair and square, but this unintentiona
+l
parsing can happen with all functions taking a list as argument, not j
+ust
print. However, only 'print' and 'printf' can have this warning trigge
+red,
with other functions are save.
But it gets more special. The warning is only triggered if there is
exactly one space between 'print' and the opening parenthesis.
print(3 + 4) * 2; # No 'interpreted as function' warning.
print (3 + 4) * 2; # 'interpreted as function' warning.
print (3 + 4) * 2; # No 'interpreted as function' warning.
The disadvantage of this warning is that it is also triggered at
perfectly valid code like:
print (3);
Therefore, I suggest we remove this warning, specially since code like
+:
print (3 + 4) * 2;
already issues a warning "Useless use of multiplication (*) in void co
+ntext",
regardless of the amount of whitespace between 'print' and the opening
parenthesis.
Abigail |
Re: print (...) interpreted as function
by bart (Canon) on Sep 02, 2003 at 15:08 UTC
|
This is one example of Perl's "helpful" warnings. Sometimes you wish it didn't do that, as in "yes I really ment to write that!". Other examples include:
- tie my %REV, Interpolation => sub { reverse shift };
- Parentheses missing around "my" list
- @a = qw(foo, bar);
- Possible attempt to separate words with commas
Maybe what we need is a global way to suppress all these "coding tips"? no warnings 'tips'; ? Or perhaps some way to set the minimum severity level of the warnings you want to see? These could be warnings of the lowest level, 1. Just a thought.
n.b. See perllexwarn for the existing hierarchy on warnings. I do see qw in that tree, but not print or my.
update: Apparently,
no warnings 'syntax';
suppresses all of these, so it could be a substitute. Unfortunalty, it also suppresses the "Useless use of integer multiplication (*) in void context" warning (for example) which personally I do not consider fluff. Oh yes, that's a nice word.
no warnings 'fluff';
| [reply]
[d/l]
[select] |
Re: print (...) interpreted as function
by fletcher_the_dog (Friar) on Sep 02, 2003 at 17:18 UTC
|
Fair and square, but this unintentional
parsing can happen with all functions taking a list as argument, not j
+ust
print. However, only 'print' and 'printf' can have this warning trigge
+red,
with other functions are save.
Since this can happen with other functions wouldn't it better to add the warning to other functions rather than take it off of "print" and "printf"? | [reply]
[d/l] |
Re: print (...) interpreted as function
by Roger (Parson) on Sep 04, 2003 at 05:54 UTC
|
Most of the time working in a larger development team, code are written to please not only oneself but also the others. I'd say the following
printf "%d", (3 + 4) * 2;
is definitely more readable than
print (3 + 4) * 2;
in a team environment. | [reply] |
|
|
When you say printf"%d",(3+4)*2; is more readable in a team environment, do you mean the code itself, or its output?
print (3+4)*2;
...is not friendly in a team environment at all. Particularly because it obfuscates what is actually going on. It will print seven (3+4), and though it's in void context, if the return value were checked, it would be two since you're multiplying print's return value by 2. The following would be more team friendly because it does what it looks like it should do.
print +(3+4)*2,"\n";
Your 'printf' example will definately be more friendly to the team, because it works. The 'print' example won't be well received by the team, because it fails to do what it sets out to do: Rather than printing 14, it prints 7. Putting the preceding '+' operator lets print know that it's looking at an expression as its parameter rather than a parameter list followed by an expression.
Dave
"If I had my life to do over again, I'd be a plumber." -- Albert Einstein | [reply]
[d/l]
[select] |
|
|
When I say printf "%d", (3+4)*2 is more readable, I meant the code itself. The output of print (3+4)*2 is certainly incorrect.
I like the print +(3+4)*2 version. Yes! the magical '+' can certainly be used here.
| [reply] |
Re: print (...) interpreted as function
by jonadab (Parson) on Sep 09, 2003 at 12:00 UTC
|
IMO, the warning in question is unnecessary and should
be removed if and only if it always occurs together with
another warning such as useless use of foo in void
context.
Does anyone know whether it's possible to trigger the
'interpreted as function' warning alone?
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l] |
|
|
$ perl -wle 'print (3) + 3 and exit if 1'
print (...) interpreted as function at -e line 1.
3
Abigail
| [reply]
[d/l] |
|
|
Ah, yes, of course. The warning exists in case some
poor C programmer tries to do something like this:
print ($x + $y) * $z || die "Unable to print, $!\n";
This shouldn't be a problem for anyone who thinks in
Perl, because Perl is nicely consistent: if it looks
like a function call, Perl treats it like a function
call. However, for fledglings who think in another
language, especially a statement-oriented language,
and try to translate into Perl, this can be a weird
gotcha. Rather than taking the warning out, perhaps
it would be better to have a way to suppress warnings
like this that have to do more with Perl semantics
than with what could be logic mistakes or typos in the
program (such as a variable only used once).
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l]
[select] |
Re: print (...) interpreted as function
by Juerd (Abbot) on Sep 01, 2003 at 16:05 UTC
|
I just send [sic] the following letter to p5p
Thank you for letting us know.
Please note that it is not necessary to post a copy of your letter here. There are web archives of p5p, so people can already read the message in their browsers.
Juerd
# { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
| [reply] |
|
|
Not necessary, but not useless either. I wonder how many users/visitors at PM don't have the p5p mail list or web archives as part of their day-to-day regimen... (I'm one such.) It's nice to have a little reverberation among the various centers of perl activity, and I'm grateful for it.
| [reply] |
|
|
I wonder how many users/visitors at PM don't have the p5p mail list or web archives as part of their day-to-day regimen
If they want to read p5p, they can read p5p. P5P posts are not PM posts, and do not belong on PM for that reason. I'm not posting #perlhelp stuff here, and fortunately, I haven't seen PM stuff on p5p yet.
Juerd
# { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
| [reply] |
|
|
I fully agree with graff's comment. I don't regularly peruse p5p, and its nice to have somebody bring potentially important stuff to my attention here, where I come daily.
| [reply] |
|
|
I don't regularly peruse p5p, and its nice to have somebody bring potentially important stuff to my attention here, where I come daily.
Read the weekly summaries on use Perl if you want to know what's going on. Note that Abigail's message is not Perl news, but just a re-post of a message to a mailing list. Of course, when any decision is made, a message in Perl News is in place.
Juerd
# { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
| [reply] |
|
|
|
|
|
|
|
