AppleScript_ The Definitive Guide - Matt Neuburg [61]
on run
display dialog "howdy"
end run
display dialog "howdy"
If you try to compile that, you will get one of the very few truly informative error messages in the whole of AppleScript: "The run handler is specified more than once , or there were top-level commands in addition to the run handler."
So, if there is an explicit run handler in a script object, that script object cannot have any top-level code. If there is no explicit run handler in a script object, that script can have top-level code and the lines of that code are its run handler (implicit).
A script object definition or a handler definition are not code. (This is another way in which these blocks are special.) The code inside them is code, of course; but they themselves are not. Thus the following script is legal and does not constitute an attempt to have two run handlers:
on run
display dialog "howdy"
end run
on sayHowdy( )
display dialog "hello"
end sayHowdy
script s
display dialog "bonjour"
end script
When a run handler is implicit, a script object definition or a handler definition at the top level is in some sense not really inside it. They really are at the top level. One way you know this is that otherwise you could never define a handler at the top level of a script. Remember, a handler nested directly in a handler is illegal. But this code is legal even though there's an implicit run handler, because the sayHowdy handler definition isn't really inside it.
on sayHowdy( )
display dialog "howdy"
end sayHowdy
But this won't compile:
on run
on sayHowdy( )
display dialog "howdy"
end sayHowdy
end run -- compile-time error: Expected "end" but found "on"
The run handler is explicit, and the sayHowdy definition is nested inside it—and a handler in a handler is illegal.
We thus have something of a paradox, because an implicit run handler can surround a handler definition without containing it in a way that makes it illegal:
set x to 1
on sayHowdy( )
display dialog "howdy"
end sayHowdy
set x to 2
In that script, the first line and the last line are in the implicit run handler, but the sayHowdy handler definition is at the top level.
For most purposes, it's not important to be constantly aware of the implicit run handler. It's easier to pretend that code can occur at the top level of a script object. So, for example, when we talk about scope, it will make most sense to speak of "set x to 1" in the preceding example as being at the top level of the script. For purposes of scope (and in other ways) an implicit run handler and an explicit run handler don't behave exactly alike. But you can't have both, so you do need to know they exist.
Variables
To complete our map of the world of a script, we must include variables. A variable is an association (formally, a binding) between a name and a value. You can think of it as a shoebox with a label on it, into which something is placed for storage. The shoebox's label is the variable's name; what's inside the shoebox is the variable's value. For example, when we say:
set x to 5
it is as if we had a shoebox labeled "x" into which we place the number 5.
Naturally, variables are very useful things, which is why just about all computer languages have them. To be able to assign your own names to things makes your program clearer and easier to maintain. And in a way any computer program is all about manipulating values, so it's nice to have a place to put each value when you're not using it, so that you can retrieve it again later. A variable's value is like the coffee in your cup when you set the cup on the table, do something else, and then pick up the cup and take a sip. The cup is like the variable; without it, the coffee would just flow onto the floor when you're not using it.
Variables and code are intimately related. Code is where variables are defined; code is where variables are given their values and where those values are retrieved.
Variables and scope blocks (handler definitions and script object definitions) are intimately related. Variables