You can't easily interpolate 'constants' as they lack the sigil, and because of that, they also get auto-quoted on the left of a fat arrow, or if it's the only thing in a hash index. Furthermore, if you see:

    my $variable = ALL_CAPS + 1;
[download]

Luckely, there's Readonly.pm:

    use Readonly;
    Readonly my $PI    => 4 * atan2(1, 1);
    Readonly my $DEBUG => 0;
[download]

Constants have the advantage of getting optimized away, when used as booleans in conditionals. Like this:

use constant DEBUG => 0;
if(DEBUG) {
    print "This will be gone.\n";
} else {
    print "Hello, world!\n";
}
[download]

Using perl -w -MO=Deparse test.pl, the outcome is:

BEGIN { $^W = 1; }
use constant ('DEBUG', 0);
do {
    print "Hello, world!\n"
};
test.pl syntax OK
[download]

with the equivalent code using Readonly,

use Readonly;
Readonly $DEBUG => 0;
if($DEBUG) {
    print "This will be gone.\n";
} else {
    print "Hello, world!\n";
}
[download]

I get this instead:

BEGIN { $^W = 1; }
use Readonly;
Readonly $DEBUG, 0;
if ($DEBUG) {
    print "This will be gone.\n";
}
else {
    print "Hello, world!\n";
}
test.pl syntax OK
[download]

Death to use constant! I've never seen the appeal of use constant, and with modern Perls, it's completely unnecessary.

I must say that you have strong arguments. Though I feel that constant.pm has some appeal. Besides, being "constants" really subs with an empty prototype and being subs with an empty prototype optimized away, they're really close to being real constants. Some times I roll my own pseudo-constants (when I need them to be closures), e.g.:

use File::Basename;

{
    my $name=basename $0;
    sub USAGE () { "Usage: $name [options] <args>\n" }
}

die USAGE unless @ARGV;
[download]

You can't easily interpolate 'constants' as they lack the sigil, and because of that, they also get auto-quoted on the left of a fat arrow, or if it's the only thing in a hash index.

Excellent points! Especially the latter. As far as the first goes, I occasionally use constant.pm's constants, but I hardly ever felt the need to interpolate any.

Furthermore, if you see:

my $variable = ALL_CAPS + 1;
[download]

does that mean that $variable becomes one more than the constant ALL_CAPS, or does $variable get the result of ALL_CAPS(1)?

Here I disagree. It is obvious that it is "one more than the constant ALL_CAPS", for the same reason as above about empty prototypes.

Luckely, there's Readonly.pm:

    use Readonly;
    Readonly my $PI    => 4 * atan2(1, 1);
    Readonly my $DEBUG => 0;
[download]

Much better, IMO.

I don't happen to use it. But indeed it's a good module, I suspect that it may introduce some overhead and maybe for "DEBUG"-like stuff constant.pm may be preferable.

IIRC, diotalevi has a module that dynamically lists all keywords for the installed perl.

Update: B::Keywords looks like the module...

Thank you for your informative post. Though the point I was trying to make is that Perl has a long story of not-completely-backward-compatible changes and it is not so unreasonable to think of a hypothetic DEBUG specially named code block, although I bet that would ring a bell amongst p5l's developers. All in all I didn't say that was a problem, just reasoning on the issue. This is a meditation after all, isn't it?

OTOH in your list I see

#define KEY_NULL                0
[download]

but that doesn't seem to make its way into Perl. I mean we do not have a NULL specially named block nor special token, have we?

Also I don't see anything about CLONE (I've never used threads myself, BTW) in your excerpt from keywords.h. Maybe it's defined elsewhere...

You are absolutely right, adding a DEBUG block would not be unreasonable, or even hard to imagine. Keywords could be added to perl (or any other language) willy-nilly, and there's not much we can do about it except get involved in the development process. We should thank Larry for giving us that option.

Good catch, in that there are missing keywords in keywords.(pl|h). I wonder if it's an oversight or by design? Is it worthy of a post to the p5p mailing list?

Subroutines whose names are in all upper case are reserved to the Perl core, as are modules whose names are in all lower case.

I must say that this seems to me an unreasonable claim on "valid-identifier space" on the part of Perl's core. I wonder why the core doesn't settle for reserving identifiers of the form __THIS_OR_THAT__, for example.

Because people don't like ugly names like that? Do read that section of the doc and see what kind of uses it is talking about. Some more recent names that have acquired special meaning: CHECK, UNTIE, CLONE, SCALAR, CLONE_SKIP.

Well, there's already ample precedent for "ugly names like that", such as __DATA__ and __PACKAGE__. Programmers need all the help they can get at the time of devising useful typographic conventions for identifiers, since the good alternatives are so few. One of these few good alternatives is the all-cap identifier, and I think it is a shame that the core has declared it off-limits.

Update: Besides, the core can still reserve specific all-cap identifiers such as the one you list, just like it reserves any other specific keyword (if, else, for, etc.). My objection is to the blanket claim on all all-cap identifiers.

the lowliest monk

In some sense you're right. But then should we have __BEGIN__ blocks? Or do you mean only with restriction to possible future reserved sub names?