Instead of non-working '+' or offending '()', you could use '&'

That's evil, I love you ;-)

Note that this has an interesting side effect that you'll never be able to observe:

use constant foo => 'bar';

sub crack {
    print &foo, $/;
}

crack(1, 2, 3);
[download]

constant creates a sub foo () { 'bar' }, that is a constant sub with empty prototype.

Using the & in front bypasses the prototype check, and it passes all arguments of sub crack to sub foo.

Now since foo is constant sub, you have no way of observing the difference - except for speed:

use Benchmark qw(cmpthese);

cmpthese(-1, {
    'ampersand' => 'use constant foo => 2; my $x = 0; for (1..10000) {
+ $x += &foo } ',
    'no_amp'    => 'use constant foo => 2; my $x = 0; for (1..10000) {
+ $x += foo } ',
});
__END__
           Rate ampersand    no_amp
ampersand 570/s        --      -39%
no_amp    939/s       65%        --
[download]

You can see that number of passed arguments makes a difference with this small benchmark:

cmpthese(-1, {
    'ampersand' => '
            use constant foo => 2; 
            sub a { my $x = 0; for (1..10000) { $x += &foo } }
            a(%ENV, %ENV, %ENV)
        ',
    'no_amp' => '
            use constant foo => 2; 
            sub a { my $x = 0; for (1..10000) { $x += foo } }
            a(%ENV, %ENV, %ENV)
        ',
});
__END__
           Rate ampersand    no_amp
ampersand 330/s        --      -61%
no_amp    849/s      157%        --
[download]

Passing a relatively large array to the sub increase the run time difference.

Thanks moritz for pointing out the speed difference which I had never considered before (not that I use & for sub calls myself).

If speed really matters, then only two solutions remain (at least known to me yet) for OP to invoke the sub (created by constant pragma) in presence of left argument quoting comma: P(), (P) (where P is some sub).

Time passes ... cdarke adds other options for invoking a sub in presence of fat comma.

Thank you for pointing out Readonly. I will certainly have a look at it, and using & is a good suggestion too. However, the quote from perldoc,

Unary "+" has no effect whatsoever, even on strings.

does IMHO not explain the observed behaviour. Note that the decision of whether or not the lhs of => is taken as expression, depends (according to the docs) on whether or not it is a bareword. This is a purely syntactical issue and does not take into account what an operator does. We have +BIRD to the left of =>, and this is certainly not a bareword.

If your interpretation of the perldoc is correct, the compiler's reasoning would go along the following line: "Hmmmm, we have +BIRD. I have no idea what BIRD is (haven't decided yet), but no matter what it is, + won't change it anyway, so just throw it away. This leaves us now with BIRD=>...., so now to the left of => we have a bareword; OK, let's quote it".

I feel that this would be a very strange approach to compiling. Kind of: Evaluating unary + very early (because it is trivial to evaluate), and keep the other operators for later (because their interpretation depends on the context).

Update: I would like to add that an unary + does work when it comes to access the element of a hash. For example, $x->{+BIRD}substitutes the constant BIRD. If your interpretation of perldoc would be correct, this expression should be treated equivalent to $x->{BIRD}, but (and IMO correctly), only in the latter case is BIRD taken as the string BIRD.

The way I read the perldoc quote posted by parv (but I'm no expert), the compiler says "Hmmmm, we have +BIRD. I have no idea what BIRD is (haven't decided yet), but no matter what it is, but there's this unary + in front of it. Lessee, that + isn't between a function and a list of arguments, so it must have no effect whatsoever. That leaves us with a bareword BIRD; I know what to do with that."

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.