it really doesn't have the notion of a "compile-time constant,"
I have to say this is incorrect. Perl has Constant Functions and their effect is compile-time, note how print "foo" is optimized away completely (edited slightly for brevity):
$ perl -MO=Deparse
use constant DOFOO => 0;
my $DOBAR = 0;
print "foo" if DOFOO;
print "bar" if $DOBAR;
__END__
use constant ('DOFOO', 0);
my $DOBAR = 0;
'???';
print 'bar' if $DOBAR;
But, in so doing, they became misleading. You might well not actually know the implementation or the behavior of the language-constructs that you are looking at.
I find this misleading because it makes it sound like there is some undefined behavior here. Whether or not a function was inlined or not should be transparent to the user. And what choroba is writing about has more to do with the autoquoting happening on the LHS of the fat comma, which is also well defined and has nothing to do with whether it's a constant function:
use Data::Dump;
use constant FOO => 123;
my $x = 455;
sub BAR { ++$x }
my %h = (
FOO => "A",
BAR => "B",
(FOO) => "C",
(BAR) => "D",
);
dd \%h;
__END__
{ 123 => "C", 456 => "D", BAR => "B", FOO => "A" }
The semantics were "grafted on,"
Constant functions have been around for something like 20 years, at least as far as I can tell from a quick look at the documentation. I'm willing to concede a couple points: 1. constant, or rather readonly, variables aren't easily usable without somewhat obscure syntax (*PI=\3.14;, see Symbol Tables) or a module like Readonly, 2. readonly variables don't have the same compile-time effect, and 3. constant functions require disambiguation when used as hash keys. However, taking the post as a whole, I'm sorry but IMO it is more FUD than fact.