Yeah, bad idea.

Consider the two proposed automatic mys in the following code. It avoids an obvious compile time fault ($line), while causing a silent run time fault ($indux).

use strict;
use warnings;

my $index = 0;
while ($line = <>)
{
  frobnicate($indux++, $line);
}
[download]

Appended Re: LanX's comment

If only applying the my to assignments initializations, then consider this code with the same issues:

use strict;
use warnings;

my $faultsInARow = 0;
while ($line = <>)
{
  if (frobnicate($line))
  {
    $faultsInaRow = 0;  #Initializing a new variable by mistake.
  }else{
    $faultsInARow ++;
  }
}
[download]

The now appended example demonstrates a case where (like mentioned before) block scoping matters.

Python has no blockscoping, such that the second assignment is not considered an declaration cause the variable has already been intialized in the "wider" scope (file or function)

Perl has blockscoping such that a command like nonlocal would be needed far too often ... or more "headache" (sic) would be needed figure out a workaround.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

This wouldn't compile when applying Python semantics, cause $indux hasn't been initialized.

So $indux=0 or my $indux would be needed beforehand to avoid compilation errors.

There are for sure more cases of uncaught typos in Python than in Perl, which blow at runtime.

But unfortunately this example doesn't demonstrate them well. :)

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

update

Update outsorced into proper post... :)

Bad idea!

Who does the work on an editor (which editor(s)?) to:

1. "prepend" the "my" to vars
2. to make the programmer's intended choice among "my," "our" and "local"
   ... and
3. to distinguish between a new global $var and one in a sub in which a $var gets localized?

Most of us find it possible to write code without too much agita over Perl's (sometimes idiosyncratic) tools that help us achieve our intent in/with the finished script.



This is a no-whining zone (well, we'd like it to be a no-whining zone!

my and our declare new variables in Perl much like int, char, float and others declare new variables in C++ (and C). Though Perl's my and our are, technically, scope specifiers while C++'s int, char, float and others are type specifiers. Still, the concept is the same: Declare new variables before you use them.

Special variables neither need to nor should be declared in your Perl code.

That is what Python2+ does (autodeclaring at first assignment), with side effects on closures, which forced Guido to introduce 'nonlocal' in Python3.

Apart from this does Python not use blockscoping¹ (IIRC) like Perl does, but only function scoping, so far less edge cases to be considered.

I wouldn't say an automine pragma would be necessarily bad, but it would cause considerable headaches to avoid incompatibilities and extra thoughts to catch typos blowing up at runtime.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

¹) i.e. block in the sense of e.g. the body of a loop

I think that, in Perl, an automine pragma would be very confusing. Currently, in the absence of strict, Perl auto-declares variables as package (aka our) variables on first use. An automine pragma would turn that on its side by auto-declaring them as local¹ (aka my) variables.

Whatever the merits of defaulting variables to local scope might be, doing so in Perl would likely be too confusing.

---

¹ as in "local scope", not "localized package variables".

The keyword my was, at some time or another, merely someone’s syntactic choice ... to go along with our, perhaps.   The key notion here is that identifiers are declared, to gaurd against typos that your eye will automatically read-over ... like the typo in this very sentence.   If “all identifiers are declared,” the compiler can, at compile time, point-out that the variable-name guard is mis-spelled and that you really didn’t intend to have two variables.

Nevertheless, the design (the philosophy?) of the Perl language is that you are given that sort of choice.   If you choose to use these compiler-features (and you should ...) then those strictures will be enforced.   But if you do not, they won’t.   Odd as it may seem to you, even “wrong” as it may seem, this is a design choice.

Many languages do carry “compile-time checking” to a much greater extreme than Perl does.   They implement strong-typing, and rely much less on at-runtime decision making to carry out The Author’s Intent.   Each approach, however, is neither right nor wrong.

Perl will never “fundamentally change,” no matter how “–er” any particular fee-chur is thought to be, because that would break the most important thing:   compatibility with the tens of millions of lines of mission-critical application code that has been written using it over the past decade(s).   The same is true of every tool that has escaped the ivory tower (or, as with Perl, never was inside of one).

The keyword my was, at some time or another, merely someone’s syntactic choice ... to go along with our, perhaps.

my came way before our...so it was 'perhaps' the other way 'round.

My, my, my ...   my mistake.   ;-)