do is a keyword (like package or use), not a function.

In your case, print is treated as a bareword . Surely this would not be surprising if you typed

use print;

instead :-)

I presume that Perl behaves in this way because it's more useful for the programmer, being more concise.

Also rememeber that if it looks like a function call, it is a function call.

-- TMTOWTDI

do print;

will evaluate print as the bareword name of a FILE and execute it.

do (print);

will evaluate print as a LIST and evaluate it as an EXPR, executing the print and then returning the result to do as a EXPR of 1.

do print();

will evaluate print as a SUBROUTINE and execute it.

The first two cases are the file-style do, the last is the old subroutine-style do, and the block-style do has not been shown.

>> perl -MO=Deparse -e 'do ("print")'
do 'print';
-e syntax OK

>> perl -MO=Deparse -e 'do (print)'
do print($_);
-e syntax OK

>> perl -MO=Deparse -e 'do print'
do 'print';
-e syntax OK

>> perl -MO=Deparse -e 'do{print}'
print $_;;
-e syntax OK
[download]

Even more curiously, do 4; produces 1 as a result with nothing in any of the error variables, as opposed to do '4'; which looks for a file. Ditto for do 2+2 which makes me think that a numeric value is being treated differently. I don't even know what it's doing! Could it be a bug, due to common code in the implementation with use and require, which indeed mean something different with numbers? Update: yes, it is doing exactly that.

As for barewords, others like do shift; is looking at is as a string, not a function, too.

My guess is that, contrary to the documentation, a bareword to do is always treated as a string (even under use strict and use warnings!) like with use.

You may want to try and see if it replaces :: with slash, like require does. It's not assuming the extension, so maybe not. But it sounds like what's happening is do/require/use is implementing some functionality at the do level, or the compiler has more in common with them than is documented.

Hopefully, a perl porter will investigate this further. I agree, it is not behaving as documented in perlfunc and perldata. My guess: common handling with use/do/require in the parser. I'd say document the "always a string", and fix the numeric context behavior to take it as a string (it's pointless to duplicate require).

Now, for the parens: That makes it a list. In scalar context, it gives the item count. Anything that's not a bareword is treated as a normal expression, and if non-numeric, the result of the expression names the file. —John

now here's an interesting ditty. When I ran case 4

$_ = 1;
do (print);
print "\n";
print $!, "\n" if $!;
[download]

output:

Perl v49.0.0 required--this is only v5.6.1, stopped at t4.pl line 2.

'Holy Oyster Farts'

mitd-Made in the Dark
'My favourite colour appears to be grey.'

On http://archive.develooper.com two bug reports (1, 2) show some other cool perl versions I cannot find anywhere on the web. ;) For instance the super cool version 123.0.0:

# from msg53551.html
jeffp@hut [1:00am] ~ #102> perl -w
sub foo { print "ok\n"; 123 }
do &foo;
ok
Perl v123.0.0 required--this is only v5.6.0, stopped (did you mean
v123.0.0?) at - line 2.
[download]

That is strange indeed. I kept experimenting and it seems when the argument to do is higher than the version of Perl running on the machine(even by fractions), that same type of error is thrown, where the 'required' version number is the same as the argument to do.

do 5.00504;
print "\n";
print $!, "\n" if $!;
# output: Perl 5.00504 required--this is only version 5.00503, stopped
+ at do.pl line 6.
[download]

Update: While using a number the same as the version of Perl, the only error thrown is:
No such file or directory

do 5.00503;
print "\n";
print $!, "\n" if $!;
# output: No such file or directory
[download]

But it's good to see that a bug has been reported on that.

Amel - f.k.a. - kel