I think the A() has at least has the advantage of being 100% clear to whoever reads the code (no one will think this might still be a bareword).
A , "Value" won't match the style of other key/pair values (or the standard notation), and ,=> looks enough like a typo (or even syntax error if you're not familiar with perl) that someone will be tempted to correct it. I agree that (A) is a beautiful solution :)

There are of course many silly alternatives, like %hash = reverse ("Value" => A, "Value" => B);, or using $::{A}->$*, but the only other correct solution I can think of is prepending the package name.

use strict;
use warnings;
use Data::Dump qw( pp );

use constant A => "One";
use constant B => "Two";
package Consts
{
  use constant C => "Three";
}

pp {
      main::A   => 1,
      ::B       => 2,
      Consts::C => 3,
    };



__DATA__
{ One => 1, Three => 3, Two => 2 }
[download]

Very nice. Thanks for sharing this choroba.

The inevitable little addendum:

Best regards, Karl

Hello karlgoethebier,

I’ve been a fan of Const::Fast since I discovered it recently in the Perl Advent Calendar 2017. But constant does have one important advantage over Const::Fast: it is applied at compile time, whereas Const::Fast takes effect only at run time. So, in this respect, Const::Fast suffers from the same limitation, identified by choroba, as the &CONSTANT syntax for the constant pragma — the constant isn’t inlined:

 0:59 >perl -Mstrict -MData::Dump -MConst::Fast -we "use constant A =>
+ 12; const our $B => 13; my %h = ( (A) => 'twelve', $B => 'thirteen')
+; dd \%h;"
{ 12 => "twelve", 13 => "thirteen" }

 0:59 >perl -Mstrict -MO=Deparse -MData::Dump -MConst::Fast -we "use c
+onstant A => 12; const our $B => 13; my %h = ( (A) => 'twelve', $B =>
+ 'thirteen'); dd \%h;"
BEGIN { $^W = 1; }
use strict;
use Data::Dump;
use Const::Fast;
use constant ('A', 12);
&const(\our $B, 13);
my(%h) = (12, 'twelve', $B, 'thirteen');
dd(\%h);
-e syntax OK

 0:59 >
[download]

(AFAICT, this also makes Const::Fast unsuitable in situations where one wants to write code like this:

use constant DEBUG => 0;
...
perform_some_debugging_operation() if DEBUG;
...
[download]

and have the compiler remove the expensive operation when it sees that DEBUG is false.)

Update: Changed perform_expensive_debugging_operation() to perform_some_debugging_operation(), because, as Eily pointed out in a private message, the cost of the operation is irrelevant if DEBUG (or $DEBUG) is false.

Cheers,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

"...the same limitation..."

Yes. Thanks. Unfortunately this is true. And i begin to see it clearly now. Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

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;
[download]

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" }
[download]

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.

I do hope the points Anon raised are among "topics for meditation", since much of the talk is about constant folding at the compile time. Anyhow, there's little to fault in his overall assessment.

Consider the enumerated constant in C:

  enum { FOO = 2 };
  enum { FOO = 3 }; // error: redefinition of enumerator
[download]

Contrast this with Perl:

  *FOO = \1.2;
  *FOO = \3.4;
  print our $FOO;   # prints 3.4
[download]

Perl has no means to protect an identifier in a given scope. This is useful for example in guarding against file level symbol clashes. (Perl isn't C, of course, but some perl modules do export lots of symbols: Fcntl, POSIX, ....)

Another sign of the problem is that constants are commonly used via hashes to keep things tidy and structured. A particular case would be the use Config. If you have conditional code-paths that depend on, say, $Config{longsize}, then these tests are not folded during compilation even though %Config::Config is supposedly read-only.