On Fri, 27 Feb 2015, Stefan Karpinski wrote:

The situation in Perl and Lua is rather different than in Julia. In Perl, the 
default scopes for unqualified variables is global, which is
really bad. You have to declare a variable using `my` in order to get lexical 
scoping; with `use strict`, you have to declare a global
variable with `our` to avoid getting complaints – this is so that strict mode 
knows that you meant for it to be a global variable and
didn't just do it by accident. Lua has the same deal – the default scope is 
global.
In Julia, this problem doesn't exist: the default scope of assigned variables 
is local. You explicitly have to declare any variable that is
assigned global if you want to create or alter a global variable; otherwise the 
assignment creates or modifies a local variable. Since the
default scope is local, Julia is effectively always in strict mode – you have 
to explicitly ask for the dangerous global scope behavior
that is the default in Perl and Lua.

Thanks you for your explanations, but most of the troubles that I have encountered, that I fear and that I would like to avoid, are unrelated to local/global scopes. Otherwise said, in Perl "use strict;" example, the feature I look for is just a part or even a side effect of it.

What I would like to catch is stuff like these pseudo-examples (the declarations syntaxes are just fancy, do not care about them (yet)):

=================
VAR newname_var          # some kind of declaration

if cond1
        newname_var=23
elseif cond2
        newname_var=19
elseif cond3
        oldname_var=55   # <== ERROR DETECTED (forgot to rename an
                         #     instance of the variable)
else
        newname_var=62
end
println("my var = $newname_var")
================

 or this:

=================
my_str :: String =""     # another kind of declaration

if cond1
        my_str="abcde"
elseif cond2
        my_str="qwerty"
elseif cond3
        mystr="azerty"   # <== ERROR DETECTED (typo)
else
        my_str="uiop"
end
println("my string is: $my_str")
================

 or this:

=================
local i=0                # another kind of declaration

while cond1
        do_something()
        if cond2
                i+=1
        end
        local j=0
        while cond3
                do_something_else()
                j+=1
        end
end
if cond4
        j=666            # <=== ERROR DETECTED (I wanted to set i, not j)
end
println("i is now $i")
================

All this kind of stupid basic mistakes which can nevertheless be a real pain to spot.

Providing an option to force some kind of declaration allows to easily get rid of a good part of those mistakes. It does not mean Julia's hypothetical implementation of this option would need to mimic other languages, it could do it its own way, as long as it somehow improves the detection os those mistakes. Perl "use strict;", Fortran "implicit none", BASIC "option explicit" have different exact purposes, but their introduction allowed to force declaration in languages where declaration was not needed at first, and that helped programmers to avoid that kind of mistakes. Now I try to stay away from Lua (and Python) because (AFAIR) they do not allow checking of declarations.


One could write a checker that requires all local variables to be declared with `local`, but that seems a little pointless when `local` is the default anyway.

But I guess something like that would be OK for me, the point of those "local" lines would be to make those declaration lines *explicit*.


You definitely don't want to have to declare every global variable since functions are globals, so you'd have to declare every function you call, which would be immensely annoying.

Well, even in that case, one could imagine checking only variables the type of which is different from "Function", I suppose. But anyway, I never use globals willingly :-) (to be fair, let us say globals represent below 0.01% of the variables I use).

I will try to check if the Lint package could be easily adapted to verify (local) variables declaration.


Faithfully yours,
  Stéphane.

Reply via email to