I mean 'my' becomes redundant, isn't it?

Also having automine would mean that using perl 5 code that wasn't written with strict would compile, but turn package variable into lexicals. So it would still compile but completely change and break the behaviour. Any changes introduced by perl 7 that are not backward compatible should be fatal, not silent.

Yes, simple lexical scoping (a variable is known from its point of declaration to end of scope) and deterministic destructors are two things I find enjoyable when using both Perl and C++ ... and I feel confused and frustrated when forced to use the ugly and complex Python scoping workarounds introduced with the global and nonlocal (sic) keywords.

To give an illustrative example, Python happily compiles and runs the typo-riddled program below, printing vanilla:

icecream_flavour = 'vanilla'
# ...
if 1:
   icecream_flavor = 'chocolate'
print(icecream_flavour)
[download]

while Perl detects the typo at compile-time:

use strict;
my $icecream_flavour = 'vanilla';
# ...
if (1) {
   $icecream_flavor = 'chocolate';
}
print $icecream_flavour;
[download]

with the error message:

Global symbol "$icecream_flavor" requires explicit package name (did you forget to declare "my $icecream_flavor"?) at t1.pl line 5.
Execution of t1.pl aborted due to compilation errors.

Update: As pointed out by LanX below, this is an unfortunate example of Python violating the Zen of Python, specifically "Explicit is better than implicit". I feel it further violates "Beautiful is better than ugly" and "Simple is better than complex" and "Errors should never pass silently" and "If the implementation is hard to explain, it's a bad idea".

See also (further update):

• Rosetta PGA-TRAM (compare the Perl and Python implementations - simple lexical scoping in Perl vs default function argument in Python)
• Re: Perl Contempt in My Workplace by QM

It took me ages to understand why and how to use the with keyword in python, until I realized it was an at attempt at recreating block-scoped variables.

I think I already had a similar discussion where LanX pointed out that python variables are lexically scoped as well, but the scope they are lexically bound to is the function, not the block. (perl decided to do block-scoped variables, but you could also imagine limitting the scope to a single expression. For example in push @out, {A => $one, b => $two} while my ($one, undef, $two) = some_function())

The system works pretty well in Python. But Perl isn't Python. One notable difference would have a major effect:

The system applies checks to rvalues. And while function arguments are rvalues in Python, sub arguments are lvalues in Perl. Same for method calls.

Were the model adopted in Perl, typos in sub arguments wouldn't be caught, and could hide typos outside of sub arguments. This would severely harm the efficacity of the system because a large amount of code consists of sub and method calls.

> Not really, it lets perl catch typos, for example if you have $the_variable_I_want_to_check = 0; somewhere in your code and then $the_varaible_I_want_to_check = 1; later, using strict and my will raise an error at compile time. Python would just silently allow it.

should be mentioned that Perl has an "used only once" warning, I'm surprised that python doesn't.

> Also having automine would mean that using perl 5 code that wasn't written with strict would compile, but turn package variable into lexicals.

automine or whatever we'd call it must obviously be a pragma extending strict, not a default feature. New pragmas breaking old code is no surprise.

update

looks like used-only-once gets deactivated with explicit declaration

#use strict;
use warnings;

my $the_variable_I_want_to_check = 0;

# somewhere in your code and then

$the_varaible_I_want_to_check = 1;
[download]

C:/Perl_524/bin\perl.exe -w d:/tmp/pm/t_typo.pl 
Name "main::the_varaible_I_want_to_check" used only once: possible typ
+o at d:/tmp/pm/t_typo.pl line 8.
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

"looks like used-only-once gets deactivated with explicit declaration"

Lexical variables and variables beginning with an underscore never trigger that warning.

toby döt ink

should be mentioned that Perl has an "used only once" warning

True, but (in the context of this thread) even that would only save you from unique typos. Make the same typo twice and the typoed name is no longer "used only once".

With your emphasis of the word "modern", you seem to be implying that variable declaration is old-fashioned and it is more modern to auto-declare them.

However, the opposite is true. Javascript introduced a strict mode in ECMAScript 5, with variable declarations required, and its use is increasingly being encouraged.

The various varieties of Visual Basic (VB.NET, VBA, etc) have "Option Explicit" which forces you to declare variables before using them. Microsoft's documentation for the language says "Setting Option Explicit to Off is generally not a good practice".

Auto-declaration has a much older history than that. For example, Fortran 77 (and probably earlier) implicitly typed variables that were undeclared based upon their first letter. Woe to those who forgot implicit none at the start of every subroutine. I am honestly horrified that Guido thought that declaring variables was a Bad Thing. Larry should have known better too, but at least use strict; disables that behavior.

---

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Perl probably inherited undeclared variables from Awk and shell, both of which create variables when they are set, in contrast to C, which requires all variables be declared with types.

The point of strict vars is to enforce the use of my to encourage appropriate scoping and to reduce badness from fat fingered identifiers. Any sort of 'automine' defeats that.

You can of course use no strict vars; to turn off strict vars so propagating bad habits to Perl 7 is only very slightly harder than using them in Perl 5.

G'day rsFalse,

I dislike your suggestion. I concur with reasons already given by others. Here's another.

Consider this (with two different $x variables):

my $x;

{
    my $x;
}
[download]

Now this (with one $x variable used in two places):

my $x;

{
    $x;
}
[download]

With no my keyword, how could the following tell these apart?

$x;

{
    $x;
}
[download]

Under the OP's "proposal", you would still be able to do

$x = 123;

{
    my $x  = 456;
}
[download]

They didn't advocate removing my, only making its use optional.

That would make this pretty confusing to newcomers though:

{
   my $x = 123;
}

say $x;
[download]

toby döt ink

> Under the OP's "proposal", you would still be able to do

I can't see that the OP made a proposal just a fuzzy wish and linking to a thread where I coined the term automine and already highlighted the problems.

>

$x = 123;
{
    my $x  = 456;
}
[download]

Your example is redundant, cause the obvious rule is that any assignment in a new scope equals a declaration.

So what's the proposal now?

Python has IMHO

• rather complicated rules, (which changed again in Py2.2 for enclosed )
• no block-scope, no loop-scope, just (nested) function-scopes ( def )
• no my to support, but the inverse nonlocal for Py3
• it's hoisting declarations to scopes start
These rules only look easy on simple cases, but closures are rather fuzzy. Given that most Pythonistas have a rather simple worldview, they don't miss closures.

This model is very hard to transfer to Perl.

Where would we steal? Ruby? Javascript?

JS is a mess, a var is

• like our outside a function
• like my inside a function
• is hoisting
JS had to introduce let to have a proper my plus an optional strict

So again WHAT is the proposal???

For the records: I'd love to be able to have an automine pragma which makes easy cases easy and complicated cases feasible.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

OK, that's a fair point; one could differentiate between the two $x variables.

I still dislike it. Given the OP has indicated "I think my idea isn't good", I don't think further discussion is necessary.

— Ken

Py3 had to introduce it, and I find it ugly.

Furthermore - and I think this is the toughest part - you'd need to clearly define the role of my under automine

I think I'm the one who coined the word automine and believe me it's far from trivial.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

It MUST be unnecessary to declare all lexical variables as lexical if 'use strict' is ON by default.

You've already seen several (very good) arguments against your proposal in previous responses, so I won't reiterate them here, but what is your argument for undermining strict with automine? Is there any reason other than "some subset of (mostly older and unmaintained, I'd wager) existing Perl code won't run under strict"?

Also, I can't help noticing that even the post you linked to as an explanation of automine calls it a bad idea. ("I think that, in Perl, an automine pragma would be very confusing... Whatever the merits of defaulting variables to local scope might be, doing so in Perl would likely be too confusing.")