You are correct in saying constant creates a subroutine. Specifically, it's a sub in the form sub NAME () { 'value' }. The empty prototype is a hint to the compiler that the value can be inlined.

The reason Readonly is slow is that it relies on a tied interface--in other words, it's an object pretending to be one of Perl's native datatypes.

One alternative is Scalar::Readonly, which sets an internal flag on a scalar (SvREADONLY). This is the flag set by certain special internal variables by Perl to make them readonly, and Scalar::Readonly lets you fiddle with it. I would be very surprised if this affected performance at all (save for the initial setting of the flag).

KEY=VALUE
KEY=VALUE
...
[download]

open(F,"config.conf");
my %config = {}'
while(<F>) {
  (my $key,$value) = split /=/;
  $config{"$key"} = $value;
}
close(F)
[download]

Here are a few tricks with read-only scalar thingies. However, you say:

Constants have to put in variables, which makes the program vulnerable to side-effects unless the programmer can guarantee that the variable can never be assigned a new value, now or in the future, or in the hands of any other person who might pick up the program.

these tricks don't guarantee anything. There's no magic implementation of Digital Rights Management in Perl :-) (or anywere else for the matter).

1. Make dynamic scalar variable read-only (idiomatic)

$ perl
*ro = \'readonly_dynamic';

print "=$ro=\n";
defined eval {$ro = 'newval'}
  or print "Exception: $@";
^D
=readonly_dynamic=
Exception: Modification of a read-only value attempted at - line 4.
[download]

2. Make lexical scalar variable read-only (w/ Lexical::Alias)

$ perl
use Lexical::Alias;
# 5.8+, see pod

my $ro;
alias ${\'readonly_lexical'}, $ro;

print "=$ro=\n";
defined eval {$ro = 'newval'}
  or print "Exception: $@";
^D
=readonly_lexical=
Exception: Modification of a read-only value attempted at - line 8.
[download]

3. Make hash (or array) element read-only (w/ Array::RefElem)

$ perl
use Array::RefElem qw/av_store hv_store/;

hv_store %h, 'ro', ${\'readonly_hashval'};
av_store @a, 5, ${\'readonly_aryelem'};

print "=$h{ro}=$a[5]=\n";
defined eval {$h{ro} = 'newval'}
  or print "Exception: $@";
defined eval {$a[5] = 'newval'}
  or print "Exception: $@";

^D
=readonly_hashval=readonly_aryelem=
Exception: Modification of a read-only value attempted at - line 7.
Exception: Modification of a read-only value attempted at - line 9.
[download]

Could you elaborate on the scoping problems use constant has? I didn't find a hint via quick googling or in its pod.

Just curious...

constant creates a subroutine, which in Perl5 is global to the package. You can fake lexically-scoped subroutines by putting them in a variable (my $sub = sub { . . . };), but that doesn't really help with constants since you can still change the variable that holds the sub ref.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

The author of Readonly elaborates in search.cpan.org/~roode/Readonly-1.03/Readonly.pm -- section "COMPARISON WITH "use constant".

? The only mention I see there of scoping is a mention that "use constant" constants are global, not lexically scoped. How is that a problem?

You can combine calin's glob assignment with local to get dynamic scoping of such constants,

{
    local *foo = \"foo";
    bar()
}
sub bar {
    print "${foo}bar$/"
}
bar();
__END__
[download]

foobar
bar
[download]

$ perl -le " use Attribute::Constant; my $pi : Constant( 3.14159265358
+9793 ); print $pi; $pi++"
3.14159265358979
Modification of a read-only value attempted at -e line 1.
[download]