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

\ 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. \

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?

\ 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. \

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. $& $' $+ $* $~ $/ $; $" $# $( $) $[ $]

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@&#8203;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@&#8203;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@&#8203;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@&#8203;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!