10.6. Scope of Undeclared Variables

In AppleScript, you do not have to declare variables. When you use a name that, by the preceding rules of scope, is not an existing variable, AppleScript does not complain; rather, it creates the variable for you. How it does this depends upon the location of the code that uses the nonexistent variable name:

Code at the top level

The variable is created as a global. There is no explicit global declaration, so there is no downward effect, but other scopes can see this variable through a global declaration. I call this an implicit global.

Code not at the top level

The variable is created as a local. I call this an implicit local .

Let's illustrate an implicit global first:

set x to 5
on getX( )
    global x
    display dialog x
end getX
getX( ) -- 5

The first line never said explicitly that x should be a global. But it clearly is one, since when getX comes along and asks to see a global called x, the x created in the first line is what it sees. (Incidentally, you can move the "set x to 5" line to after the getX handler definition and the script will still work; the important thing is that the global x be defined by the time getX runs, not necessarily before getX itself is defined.)

Incidentally, a variable created implicitly in a script's top-level explicit run handler is an implicit global as well, just as if you'd declared it at the absolute top level:

on run
    set howdy to "Howdy"
    sayHowdy( ) -- Howdy
end run
on sayHowdy( )
    global howdy
    display dialog howdy
end sayHowdy

That's a very odd rule, as in no other respect (I believe) is an explicit run handler treated like the absolute top level; usually, it's treated like a handler, in which case the implicit variable would be local. This shows the extremes the language goes to in order to cope with undeclared variables.

Now for an implicit local:

set x to 5
on getX( )
    set x to 10
    display dialog x
end getX
getX( ) -- 10
display dialog x -- 5

Clearly we are now talking about two different variables called x. We have already established that the top-level x is global; but getX is evidently not seeing it. It is setting to 10, and displaying, some other x; its actions are having no effect on the top-level x, as the last line proves. So getX's x must be local to getX. To prove that it is truly local and not some sort of magic downward global within getX, we need another test:

script s
    set x to 10
    on myHandler( )
        display dialog x
    end myHandler
    myHandler( )
end script
run s -- error: The variable x is not defined

But if we reverse the structurea script object in a handler, instead of a handler in a script objectthen it works:

on getX( )
    set x to 10
    script s
        display dialog x
    end script
    run s
end getX
getX( ) -- 10

That isn't because x is not local; it's because of the special exceptional rule that a script object in a handler can see the handler's locals.