develooper Front page | perl.perl5.porters | Postings from April 2013

controlling literal variable names

Thread Next
Ricardo Signes
April 22, 2013 20:15
controlling literal variable names
Message ID:

There are a bunch of variables in the form $^A, where A is some upper case
ASCII letter.  These variables magically get stored under the name \cA.  So,
these two lines do the same thing:

  say $^T;
  say ${"\cT"};

What's more, it's legal to put a literal ^T in the perl program:

  say $; # <-- that's a literal ^T after the dollar sign there

Why?  So far, I have yet to find a great reason that it was allowed.  It came
up as weird / problematic here:

  use feature 'say';
  say "version $^V";
  $^K = 123;
  say "^K: " . $^K;
  say "cK: " . ${"\cK"};
  say "+K: " . $^K; # <-- literal ^K in my source

This program prints:

  version v5.12.4
  ^K: 123
  cK: 123
  +K: 123


  version v5.17.10
  ^K: 123
  cK: 123

...because, more or less, \cK is whitespace now.  (This might not be exactly
right, but let's roll with that.)  So, we say "you can't use the literal
control character if it would be whitespace."  But on EBCDIC platforms \cT
would be whitespace!

Rather than grump and blame EBCDIC, I think the solution is to call the literal
control form bogus, value-free, and best disposed of.  I propose that we
deprecate this form of literal variable in 5.19 for removal in 5.21.  If you
want $^P, you say $^P or ${"\cP"} and can no longer use a literal ^P character.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About