use strict 'vars'

[p5pRT]

Migrated from rt.perl.org#1979 (status was 'resolved')

Searchable as RT1979$

[p5pRT]

From ccadieux@ccadieux.Central.Sun.COM

[Please enter your report here]
use strict 'vars' seems to ignore the variables '$a' and '$b'. It works
fine for '$c', '$d' ...

#/usr/bin/perl
use strict 'vars';

$a = 2;

# this code should not work but does.

Site configuration information for perl 5.003​:

Configured by eric at Mon Sep 16 15​:29​:50 PDT 1996.

Summary of my perl5 (5.0 patchlevel 3 subversion 0) configuration​:
  Platform​:
  osname=solaris, osver=2.5.1, archname=sun4-solaris
  uname='sunos m-e-ir1 5.5.1 generic sun4u sparc sunw,ultra-1 '
  hint=recommended, useposix=true, d_sigaction=define
  Compiler​:
  cc='cc', optimize='-O', gccversion=
  cppflags=''
  ccflags =''
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  voidflags=15, castflags=0, d_casti32=define, d_castneg=define
  intsize=4, alignbytes=8, usemymalloc=y, randbits=15
  Linker and Libraries​:
  ld='cc', ldflags =''
  libpth=/lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
  libc=/lib/libc.so, so=so
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=, ccdlflags=' '
  cccdlflags='-Kpic', lddlflags='-G'

[p5pRT]

From @tamias

On Tue, Jan 11, 2000 at 01​:08​:20PM -0700, Christian Cadieux wrote​:

This is a bug report for perl from ccadieux@​central.sun.com,
generated with the help of perlbug 1.13 running under perl 5.003.

[Please enter your report here]
use strict 'vars' seems to ignore the variables '$a' and '$b'. It works
fine for '$c', '$d' ...

#/usr/bin/perl
use strict 'vars';

$a = 2;

# this code should not work but does.

$a and $b are special-cased because they are used by sort subroutines.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

use strict 'vars' seems to ignore the variables '$a' and '$b'. It works
fine for '$c', '$d' ...

#/usr/bin/perl
use strict 'vars';

$a = 2;

# this code should not work but does.

  % man strict
  ....
  `strict vars'
  This generates a compile-time error if you access a variable
  that wasn't declared via `use vars', localized via `my()'
  or wasn't fully qualified. Because this is to avoid variable
  suicide problems and subtle dynamic scoping issues, a merely
  local() variable isn't good enough. See the my entry in the
  perlfunc manpage and the local entry in the perlfunc manpage.

  use strict 'vars';
  $X​::foo = 1; # ok, fully qualified
  my $foo = 10; # ok, my() var
  local $foo = 9; # blows up

  package Cinna;
  use vars qw/ $bar /; # Declares $bar in current package
  $bar = 'HgS'; # ok, global declared via pragma

  The local() generated a compile-time error because you just
  touched a global name without fully qualifying it.

----> Because of their special use by sort(), the variables $a and
----> $b are exempted from this check.

Perhaps they should be listen in perlvar as well. I notice @​F is
also missing from perlvar. What else are we forgetting?

I further note that `man strict' doesn't mention Larry's spiffy new
our() operator. Oughtn't it?

--tom

[p5pRT]

From @TimToady

Tom Christiansen writes​:
: >use strict 'vars' seems to ignore the variables '$a' and '$b'. It works
: >fine for '$c', '$d' ...

Perhaps perlbug should refuse to post a report containing the words
"strict", "$a", and "$b". :-)

: I further note that `man strict' doesn't mention Larry's spiffy new
: our() operator. Oughtn't it?

Yup. I missed that one.

Larry

[p5pRT]

From [Unknown Contact. See original ticket]

Ronald J Kimball wrote​:

On Tue, Jan 11, 2000 at 01​:08​:20PM -0700, Christian Cadieux wrote​:

This is a bug report for perl from ccadieux@​central.sun.com,
generated with the help of perlbug 1.13 running under perl 5.003.

[Please enter your report here]
use strict 'vars' seems to ignore the variables '$a' and '$b'. It works
fine for '$c', '$d' ...

#/usr/bin/perl
use strict 'vars';

$a = 2;

# this code should not work but does.

$a and $b are special-cased because they are used by sort subroutines.

Ronald

<rant>
I'm sure there is a really good reason that user defined sort subs
use the global/local/univeral/magical variables $a and $b to determine
sorting order, rather than having the sort routine look at a less painful
variable, such at @​_. faster, less memory, something.

but from a user point of view, its a hidden gotcha.
I recall writing some code that unknowingly used the $a $b
variables (ran out of $i, $j, $k, $x, $y, $z) and had some
weird behaviour that I didn't figure out until I asked a perl "guru".

could perl spit out some kind of note when it encounters $a or $b
such as "this is a weird variable reserved for sorting."
just to inform a neophyte that $a is not the same as $c .. $z?
that the perl people know about it, and that the user should
probably use a different variable?

would it be too much to rename it to something less likely to
collide with the neophyte? maybe $_sorting_variable_a_

if there isn't much of a performance/memory/etc hit, could
it use @​_ since the sort routine must be a subroutine?

I don't like global variables to begin with.
</rant>

sorry, doing test vectors today, and just in a generally bad mood.

;(

Greg

[p5pRT]

From [Unknown Contact. See original ticket]

I'm sure there is a really good reason that user defined sort subs
use the global/local/univeral/magical variables $a and $b to determine
sorting order, rather than having the sort routine look at a less painful
variable, such at @​_. faster, less memory, something.

Was that a question?

but from a user point of view, its a hidden gotcha.

I fail to see how something that it is documented can be adjudged
"hidden". Neither do I understand how something that has worked in that
fashion since time immemorial (perl-wise) is "hidden". What, pray tell,
might we have to do to make it "not hidden"? Make it the first thing
in the the perl(1) manpage? Do you have a suggested patch to perlvar(1)?

I recall writing some code that unknowingly used the $a $b
variables (ran out of $i, $j, $k, $x, $y, $z) and had some
weird behaviour that I didn't figure out until I asked a perl "guru".

Perhaps this is a special penalty for those with insufficient
imagination to use properly named variables. :-)

could perl spit out some kind of note when it encounters $a or $b
such as "this is a weird variable reserved for sorting."
just to inform a neophyte that $a is not the same as $c .. $z?
that the perl people know about it, and that the user should
probably use a different variable?

Goodness, I don't think so.

would it be too much to rename it to something less likely to
collide with the neophyte? maybe $_sorting_variable_a_

Only if breaking it in that odious fashion should cause Perl to emit
your name, email address, and home phone number.

First of all, there's no reason to shamelessly destroy all existing sort
code. Secondly, designing something to be novice-friendly at the expense
of making it expert-hostile is a fundamental error, for you shall be a
novice but once and briefly, yet a trans-novice for all the days of your
life that follow your initiation into these the outermost mysteries.
Thirdly, so long a variable name as that is completely repugnant.
It reminds me of the same sentiment as drives the misguided to write

  for ($loop_index_variable = 0;
  $loop_index_variable < scalar(@​array);
  $loop_index_variable = $loop_index_variable + 1
  )
  {
  $cumulative_sum = $cumulative_sum
  + $an_array_variable[$loop_index_variable];
  }

if there isn't much of a performance/memory/etc hit, could
it use @​_ since the sort routine must be a subroutine?

Sure, as long as you agree that Perl should in perpetuity emit your real
home phone number because you decided to hose a million people because
you stubbed your toe. Eschew immediate gratification.

I don't like global variables to begin with.

Then perhaps you shouldn't use them. Deal? :-)

--tom

[p5pRT]

From @TimToady

london@​pixelmagic.com writes​:
: I'm sure there is a really good reason that user defined sort subs
: use the global/local/univeral/magical variables $a and $b to determine
: sorting order, rather than having the sort routine look at a less painful
: variable, such at @​_. faster, less memory, something.

Speed and notational convenience.

In a very recent development version of Perl, if you use a sort sub
with a ($$) prototype, it'll give you the arguments in @​_. Eventually
you'll be able to use a prototype of ($a, $b) and get them back into
$a and $b, only as lexicals.

Larry

[p5pRT]

From [Unknown Contact. See original ticket]

you can be quite hubritic sometimes, really.

I start out by saying "I'm sure there was a reason it was done this way"
followed by saying its a weird exception to the norm.
I then ask if there were anyway that the exception could be redone
so that it doesn't trip up the neophytes.

your response it to reject the idea out of hand,
with no explanation of the reasons it was originally done that way,
and with nothing but sarcastic remarks on the suggestions offered.

given that any language is useless if there aren't any people using
it, may I suggest that if you wish to forward perl, it isn't
simply "what you know" that's important.

You are a veritable wealth of knowledge on the subject of perl and
its intracacies. but perl isn't about what you know. its about
what other people can learn and use for themselves.
(for perl developers, perl is about getting someone else's job done.)

if anyone asks an honest perl question and you reply with sarcasm,
I'd say you are doing a disservice for the whole of perl.

specific responses below​:

Tom Christiansen wrote​:

I'm sure there is a really good reason that user defined sort subs
use the global/local/univeral/magical variables $a and $b to determine
sorting order, rather than having the sort routine look at a less painful
variable, such at @​_. faster, less memory, something.

Was that a question?

but from a user point of view, its a hidden gotcha.

I fail to see how something that it is documented can be adjudged
"hidden". Neither do I understand how something that has worked in that
fashion since time immemorial (perl-wise) is "hidden". What, pray tell,
might we have to do to make it "not hidden"? Make it the first thing
in the the perl(1) manpage? Do you have a suggested patch to perlvar(1)?

people expect computer languages to all behave pretty much the same.
a conditional statement should be pretty straighforward.
so should the use of variables. It's arrogant to demand that people
read all the man pages before they start their first perl program
so they discover all the exceptions to the rules of normal
computer language behaviour.

I recall writing some code that unknowingly used the $a $b
variables (ran out of $i, $j, $k, $x, $y, $z) and had some
weird behaviour that I didn't figure out until I asked a perl "guru".

Perhaps this is a special penalty for those with insufficient
imagination to use properly named variables. :-)

could not the same penalty be applied to Perl for using
$a and $b as names for sorting variables then?
should we broadcast that person's name and phone number
to the universe for that decision?

could perl spit out some kind of note when it encounters $a or $b
such as "this is a weird variable reserved for sorting."
just to inform a neophyte that $a is not the same as $c .. $z?
that the perl people know about it, and that the user should
probably use a different variable?

Goodness, I don't think so.

we can put a man on the moon, but we can't do this ....

would it be too much to rename it to something less likely to
collide with the neophyte? maybe $_sorting_variable_a_

Only if breaking it in that odious fashion should cause Perl to emit
your name, email address, and home phone number.

First of all, there's no reason to shamelessly destroy all existing sort code.
Secondly, designing something to be novice-friendly at the expense
of making it expert-hostile is a fundamental error, for you shall be a
novice but once and briefly, yet a trans-novice for all the days of your
life that follow your initiation into these the outermost mysteries.
Thirdly, so long a variable name as that is completely repugnant.
It reminds me of the same sentiment as drives the misguided to write

for \($loop\_index\_variable = 0;
     $loop\_index\_variable \< scalar\(@&#8203;array\);
     $loop\_index\_variable = $loop\_index\_variable \+ 1
    \)
\{
    $cumulative\_sum = $cumulative\_sum
                    \+ $an\_array\_variable\[$loop\_index\_variable\];
\}

figure out the number of sorting subroutines that exist in perl
that use $a $b, multiply that by the number of characters in a
long variable name (say 15), and you will still have fewer additional
characters than is found in any of your common rants on p5p.

Upon packing his bags in preparation for a journey, the savvy traveller
discards fully fifty percent of his stowed possessions, for he realizes
that needless clutter and gratuitous baggage but weigh him down and
distract him from his goal. It is only after many years of repeated
mistakes that the truly seasoned traveller can a priori recognize
unjustifiable bloat for its hidden promise of inevitable annoyance.

that rant alone should fully exceed the number of characters needed to expand
all sorting routines in perl such that
s/\$a/\$_sort_a_/ and
s/\$b/\$_sort_b_/

if there isn't much of a performance/memory/etc hit, could
it use @​_ since the sort routine must be a subroutine?

Sure, as long as you agree that Perl should in perpetuity emit your real
home phone number because you decided to hose a million people because
you stubbed your toe. Eschew immediate gratification.

is that such a foolish suggestion?
am I misunderstanding what Larry Wall said here?

Larry Wall wrote​:

In a very recent development version of Perl, if you use a sort sub
with a ($$) prototype, it'll give you the arguments in @​_. Eventually
you'll be able to use a prototype of ($a, $b) and get them back into
$a and $b, only as lexicals.

it looks like @​_ would get rid of the globals and everyone would be happy.

Greg

"Waiter, a round of diligence, patience, and humility
for everyone at the bar, including myself."

[p5pRT]

From [Unknown Contact. See original ticket]

From the number of cheap shots TomC has been making recently, I'd say
something has him in a bad mood. But that aside, has everyone given up
hope on backwards-compatibly catching $a and $b problems?

<strawman> Warn on uses at the toplevel scope (or scopes without a
subroutine definition ancestor). Queue up the warnings for all other
scopes, and track which things are definitely used as sort subs in the
same compile. Wipe those out, and emit the remaining warnings at the end
of the compile. Don't worry about the cases that slip through the
cracks. </strawman>

Maybe that's totally insane, I don't know.

Given that this "bug" report arises so frequently, why was I unable to
find any mention in the 5.5.62 docs? I didn't try that hard, but no
perlfaq entry, no mention in strict.pm, no perltrap entry. The following
are people's strict.pm patches -- why aren't they in?​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-12/msg00009.html
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-12/msg00179.html

There is a mention in perlfunc, but judging from the number of reports,
that's not enough. It strikes me as wartlike enough in behavior to merit
quite a few notices in the documentation.

[p5pRT]

From [Unknown Contact. See original ticket]

Sigh. Do I really have to answer all this? It is completely
unconscionable to break existing code by outlawing $a and $b.
It in unfathomable that this should have been requested.

End of story.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

Sigh. Do I really have to answer all this? It is completely
unconscionable to break existing code by outlawing $a and $b.
It in unfathomable that this should have been requested.

Don't break anything, but possibly produce incorrect warnings. If new
warnings are regarded as breakage, we're screwed. I know use strict
'vars' currently produces errors, not warnings, but it's not a big leap
to convert those to warnings for $a and $b only. Perhaps you wanted me
to mention that detail.

Correct me if I'm wrong, but I thought the oft-repeated bug report is
"use strict doesn't work for $a and $b." If use strict said clearly "$a
is a special case, so this warning might be in error", you won't see the
bug report any more. Especially not if it's rarely in error, which is
not impossible.

Or not, if you're no longer reading my sentences that aren't too many
negatives piled on top of each other.

[p5pRT]

From [Unknown Contact. See original ticket]

Don't break anything, but possibly produce incorrect warnings. If new
warnings are regarded as breakage, we're screwed. I know use strict
'vars' currently produces errors, not warnings, but it's not a big leap
to convert those to warnings for $a and $b only. Perhaps you wanted me
to mention that detail.

If you suddenly produce a warning just because someone was using
$a and $b, you will be shot. Not by me, but by millions of users.
But if you make it $some_idiotically_long_variable_a, then you won't
be shot by millions of users--because this time I'll be at the front
of the line.

If you dont' believe me, try it. Here's an "I told you so" in
advance.

Correct me if I'm wrong, but I thought the oft-repeated bug report is
"use strict doesn't work for $a and $b."

"use strict" doesn't "work" for a lot of other variables, either,
like @​F and $_ and @​_ and %_ and $ARGV and @​ENV and $. and $!, too.
The allegation that there wasn't enough code out there using $a and
$b for us to care about it got the answer it deserves.

The novice issue is a red herring, and the "all programs do work (or should
work) the same way" was so silly I burst out laughing. I hope you
don't want me to answer that one, too. The answer is self-evident.

If use strict said clearly "$a
is a special case, so this warning might be in error", you won't see the
bug report any more.

I do believe I suggested a documentation patch.

Finally, the notion that "using single-letter variable names is a
crime that carries its own punishment" is especially apt here.

You can't "outlaw globals". That's not what use strict does, you know.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Steve Fink (lists.p5p)​:

Correct me if I'm wrong, but I thought the oft-repeated bug report is
"use strict doesn't work for $a and $b." If use strict said clearly "$a
is a special case, so this warning might be in error"

Well, it does, in the documentation of strict.pm, if you read the
current version.

I regard this as having fixed the problem, when changes in the strict.pm
POD filter through to a stable release. If it's documented, and does
what it's documented to do, it's not a bug; it just means some people won't
carefully read the documentation.

Maybe you think providing accurate documentation isn't enough, and we
should produce hand-holding warning messages to cope for these sorts of
people. Do you think a warning every time someone uses (localtime)[5]
would get rid of the oft-repeated Y2K bug report?

--
And no, the moon ain't romantic // it's as intimidating as hell - Tom Waits.

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

?Correct me if I'm wrong, but I thought the oft-repeated bug report is
?"use strict doesn't work for $a and $b."

"use strict" doesn't "work" for a lot of other variables, either,
like @​F and $_ and @​_ and %_ and $ARGV and @​ENV and $. and $!, too.
The allegation that there wasn't enough code out there using $a and
$b for us to care about it got the answer it deserves.

I think its interesting that most of perl's globals look like hieroglyphs.
$&amp; $' $+ $* $~ $/ $; $" $# $( $) $[ $]

such names have near zero chance that a neophyte would accidently stumble onto them.
how many bug reports say "use strict doesn't work for $." ???
I say someone designing perl made a bad decision from a users standpoint
when they used a global variable with a "normal" name of $a and $b.

what about changing the global to some form of hieroglyph?
$#[ and $#] or some such nonsense, that should avoid
anyone from accidently using it, and should keep Tom's hands
from cramping up from too much typing.

then spit out a warning saying $a $b has been deprecated,
all code will still run, but occurences of $a $b in sort routines
will be quickly rooted out by the warning messages.

The novice issue is a red herring, and the "all programs do work (or should
work) the same way" was so silly I burst out laughing. I hope you
don't want me to answer that one, too. The answer is self-evident.

for every exception added to perl, the more un-usable perl becomes.
I'm glad you can find humor in that.

it's generally said that perl tries to "do the right thing"
I'm simply asking the same of the perl designers.

a bad decision was made to use $a and $b as global sort variables.
why is it so outlandish to suggest it be corrected?

I'd guess there are 20 *.pm files in the perl distribution
that would need to be updated so that their sort routines
use the new hieroglyph. I could go through them and change
all $a $b to their new hieraglyph in a couple of days, part time.

why the outrage?

Greg

[p5pRT]

From [Unknown Contact. See original ticket]

You forgot a lot of other globals, like $STDIN and %ARGV.

then spit out a warning saying $a $b has been deprecated,
all code will still run, but occurences of $a $b in sort routines
will be quickly rooted out by the warning messages.

If we want to rewrite Perl, fine. Failing that, not fine.

I'd guess there are 20 *.pm files in the perl distribution
that would need to be updated so that their sort routines
use the new hieroglyph. I could go through them and change
all $a $b to their new hieraglyph in a couple of days, part time.

Those twenty files are irrelevant. You cannot expect to
be able to go around CHANGING EVERYBODY ELSE'S CODE. And
that is where my concern resides. It is not in the code
in the distribution, about which I couldn't care one whit less.

why the outrage?

Because it is arrogant to make these high-and-mighty decisions
about how people "should" be programming just so that they'll
conform to *your* puritanical maxims.

I have a much better idea​: go learn what $a and $b are for in sort
routines. I'm sure you'll find that to be much easier than changing
the world.

THOU SHALT NOT SCREW WITH EXISTING CODE.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

it is arrogant to make these high-and-mighty decisions
about how people "should" be programming just so that they'll
conform to *your* puritanical maxims.

THOU SHALT NOT SCREW WITH EXISTING CODE.

and that would that be *your* puritanical maxim then?
come down from the mountain, Tom, you're neither god nor moses.

I never claimed to have the answer, I only asked why it was
done the way it was done, and asked why couldn't it be done
this other way or that other way. I was looking for the
benefit versus cost comparison.

but if the weight of backward compatibility is infinite,
as you imply with your written-in-stone commandment,
then the scales will always be tipped in the favor or
never changing anything that's been added to perl,
regardless of how much it might have turned into a
piece of shit.

Greg

[p5pRT]

From [Unknown Contact. See original ticket]

and that would that be *your* puritanical maxim then?

Your skill at detecting irony is, I note, only halfway developed.

I never claimed to have the answer, I only asked why it was
done the way it was done, and asked why couldn't it be done
this other way or that other way. I was looking for the
benefit versus cost comparison.

There's a big difference between "couldn't be done" and "couldn't
have been done". We can't screw up $a and $b just to fit your
prurient interests that somewhere, someone might someday do something
immoral with those variables. If you want to discuss hypotheticals
in the past, feel free, but it's a waste of time lobby to change
perl to screw people who you feel deserve it.

And don't be surprised if replies contain the same tone as the
your own self-styled rants.

Hope this helps,

-tom

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, Jan 13, 2000 at 02​:49​:55PM -0500, "london@​pixelmagic.com" wrote​:

Tom Christiansen wrote​:

it is arrogant to make these high-and-mighty decisions
about how people "should" be programming just so that they'll
conform to *your* puritanical maxims.
THOU SHALT NOT SCREW WITH EXISTING CODE.
...
but if the weight of backward compatibility is infinite,
as you imply with your written-in-stone commandment,
then the scales will always be tipped in the favor or
never changing anything that's been added to perl,
regardless of how much it might have turned into a
piece of shit.
Greg

I think Tom would be perfectly happy with 5.004 living forever. :-)

mark

P.S. For a few projects, I am currently _ON PURPOSE_ using perl5.004. I
  think a few other people are doing the same... It's not that I don't
  like the changes that are being made to perl, as I believe I do, it's
  more the instablity that scares the shit out of me.

--
markm@​nortelnetworks.com/mark@​mielke.cc/markm@​ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
  and in the darkness bind them...

  http​://mark.mielke.cc/

[p5pRT]

From [Unknown Contact. See original ticket]

Ronald J Kimball wrote​:

Wow, I'd hate to see how worked up you get over a Perl problem that _isn't_
completely trivial.

point taken.

my apologies to everyone on the list for any emails that got out of line.

Greg
"waiter, another shot of humility, make it a double."

[p5pRT]

From @TimToady

london@​pixelmagic.com writes​:
: then spit out a warning saying $a $b has been deprecated,
: all code will still run, but occurences of $a $b in sort routines
: will be quickly rooted out by the warning messages.

I like $a and $b. It's just that lexicals hadn't been invented yet,
or they'd have been lexicals, not globals.

Larry

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

Don't break anything, but possibly produce incorrect warnings. If new
warnings are regarded as breakage, we're screwed. I know use strict
'vars' currently produces errors, not warnings, but it's not a big leap
to convert those to warnings for $a and $b only. Perhaps you wanted me
to mention that detail.

If you suddenly produce a warning just because someone was using
$a and $b, you will be shot. Not by me, but by millions of users.
But if you make it $some_idiotically_long_variable_a, then you won't
be shot by millions of users--because this time I'll be at the front
of the line.

If you dont' believe me, try it. Here's an "I told you so" in
advance.

Hm. TomC, you seem to be responding to my suggestions as if they were
the union of my actual suggestions and Greg's. I do not have the least
desire to rename $a or $b. I do not want to affect sort { $a <=> $b } at
all either. sub mysort { $a <=> $b } I'm not entirely convinced must be
preserved forever, but leave that aside for now.

Yes, I am proposing issuing a warning just because someone was using $a
or $b -- but only in the hopefully rare cases that perl has an incorrect
but strong suspicion that they aren't being used as sort variables. sort
BLOCK would never issue such a warning (I mean, if the $a or $b were
actually present in the block and not in a called subroutine). $a = 5 at
the toplevel scope would, but then, unless I have a severe lack of
imagination, that warning would always be correct. sub mysort might once
in a while issue an incorrect warning, but normally wouldn't.

If use strict said clearly "$a
is a special case, so this warning might be in error", you won't see the
bug report any more.

I do believe I suggested a documentation patch.

I was assuming the implementation of the above proposal, and the message
is in perldiag or maybe the warning issued, not the documentation.

Finally, the notion that "using single-letter variable names is a
crime that carries its own punishment" is especially apt here.

Much of the example code in the documentation uses $a, $b, and $c.
Justifiably, since the purpose of the variables is not relevant to the
lesson being imparted. But first, that means that many people will be
using them; and second, there are many instances in actual code where
the purpose of variables is irrelevant.

my $a, $b; # oops!
# Set $a and $b to something useful, then
($$a, $$b) = ($$b, $$a);

Forbidding $a and $b in general and in these kinds of situations in
particular is rather bizarre and not the way I think of perl doing
things. Go ahead and do weird things with $; if you like; leave $a with
$x. Scowling at single-letter variables is much the same as demanding
that every line of code contain a comment. Or taking away all the
prepositions that people were using to end their sentences with. Most of
the time it's a great idea, but all of the time it's not.

[p5pRT]

From [Unknown Contact. See original ticket]

Generic examples that use $a and $b should perhaps use $x and $y instead.

--tom

[p5pRT]

From @TimToady

Tom Christiansen writes​:
: Generic examples that use $a and $b should perhaps use $x and $y instead.

Over the long haul, this will not be an issue, since explicit sort
subroutines will switch to ($a, $b) prototypes, and inline sorts will
have an implicit prototype of ($a, $b). In either case, $a and $b will
be lexicals scoped to the sort sub.

At that point we could deprecate unprototyped sort subs if we want to.

Once all the unprototyped sort subs are gone, we can make "use strict vars"
complain on $a and $b.

Larry

[p5pRT]

From @TimToady

Mark Mielke writes​:
: P.S. For a few projects, I am currently _ON PURPOSE_ using perl5.004. I
: think a few other people are doing the same... It's not that I don't
: like the changes that are being made to perl, as I believe I do, it's
: more the instablity that scares the shit out of me.

You'll note that every version of Perl from version 1 through version 4
was a development version, not a maintenance version. Yet people were
pretty happy with it, partly because we had a policy of backward
compatiblity, but mostly because we enforced that policy with
regression tests.

So people who are worried about Perl breaking should be writing more
regression tests.

And before anyone submits a patch for it, I'm not talking about testing
for features like the non-existence of delete(@​a)... :-)

Larry

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, Jan 13, 2000 at 01​:16​:29PM -0800, "Larry Wall" wrote​:

Mark Mielke writes​:
: P.S. For a few projects, I am currently _ON PURPOSE_ using perl5.004. I
: think a few other people are doing the same... It's not that I don't
: like the changes that are being made to perl, as I believe I do, it's
: more the instablity that scares the shit out of me.
You'll note that every version of Perl from version 1 through version 4
was a development version, not a maintenance version. Yet people were
pretty happy with it, partly because we had a policy of backward
compatiblity, but mostly because we enforced that policy with
regression tests.

That's not what I saw when people were recommending perl5.005_53 over
perl5.005_03... :-)

Sorry... perl5.004 with the maintenance patches is perfect for the rock
solid stability I needed in a few of the projects...

For everything else I use the latest and greatest that I happen to have
found time to compile.

I didn't mean that to come across quite as negative as perhaps it did. I
was just partially defending the "perl is fine the way it is" bunch.

Personally, I think language evolution is necessary, else extinction
is the inevitable result.

mark

--
markm@​nortelnetworks.com/mark@​mielke.cc/markm@​ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
  and in the darkness bind them...

  http​://mark.mielke.cc/

[p5pRT]

From @RandalSchwartz

"Larry" == Larry Wall <larry@​wall.org> writes​:

Larry> You'll note that every version of Perl from version 1 through
Larry> version 4 was a development version, not a maintenance version.
Larry> Yet people were pretty happy with it, partly because we had a
Larry> policy of backward compatiblity, but mostly because we enforced
Larry> that policy with regression tests.

Larry> So people who are worried about Perl breaking should be writing more
Larry> regression tests.

Just weighing in​:

1) Let's not break @​a = $[ + $#a + 1, in any event, for any reason.

2) If exists() can detect some change in state in a pseudo-hash, then
  delete() better durn well be available to force such a change.
  So either fix exists(), or make delete() work.

3) There is nothing for item 3. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@​stonehenge.com> <URL​:http​://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[p5pRT]

From @RandalSchwartz

"Randal" == Randal L Schwartz <merlyn@​stonehenge.com> writes​:

Randal> 1) Let's not break @​a = $[ + $#a + 1, in any event, for any reason.

Well, except to get the math right. @​a = $#a - $[ + 1. :)

Bleh. One of those lifetimes. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@​stonehenge.com> <URL​:http​://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!