Re^4: Constant names come into conflict with Perl style?

[dmitri]

Whether constants should have a sigil is also subject to philosophical debate: for instance, DEBUG just does not look like a potential lvalue, while $DEBUG does.

As for placing this into "Meditations," I am not sure that a question this short belongs there. I am simply asking for opinions, as I think I have stumbled upon a contradiction in Perl's conventions.

[Tanktalus]

for instance, DEBUG just does not look like a potential lvalue, while $DEBUG does.

++. I've never looked at it that way, and I like it. Thanks.

That said, Perl6 seems to use the construct:

  my $foo is readonly = 12;

so we will have the issue come up again: $foo looks like an lvalue, but isn't. Further, I think we will be able to define sub's as rvalues, further confusing the issue. ;-)

[TimToady]

The readonly trait is intended primarily to mark a variable as readonly despite its underlying value being writable. It's the default for formal parameters, so while it's set on many variables, you won't actually see the word "readonly" terribly often unless you want to nail down a variable as a pseudo-constant over some scope.

What you will see more of is the constant declarator. Just put "constant" where you would have put "my", like this:

   constant $foo = 12;

This declares a true compile-time constant, lexically scoped. Any place the compiler sees $foo, it's free to substitute in 12. The item declared need not have a sigil on the front as long as it's a valid identifier:

   constant Int foo = 12;

That just makes it a bit harder to interpolate. Instead of $foo you'd have to say {foo}. But any valid identifier also includes Unicode, so you can even say:

   constant Num π = atan(2,2) * 4;

Note that the expression is evaluated at compile time, whereas readonly on a normal my evaluates at run time.