AppleScript_ The Definitive Guide - Matt Neuburg [34]
Compiling and Decompiling
To compile your AppleScript code is a necessary intermediate step between editing it and running it. This section explains what this means, and then discusses some of the implications for you, the AppleScript programmer.
Compiling
To compile code means to transform it from editable text to a form that is understood by some engine that will run the code. The particular form depends upon the nature of the particular engine. At one end of the spectrum, the engine might be the computer's central processing unit (CPU), in which case the code is turned from text to machine-language instructions; that, for example, is how Fortran and C work. At the other end of the spectrum, one can postpone compilation until the program is actually running and a line of code is encountered; for example, in some implementations of BASIC , such as the one that came with the original Apple II, the runtime engine accepts pure text, compiling and executing that text one line at a time. A language that works this way is said to be interpreted.
In the early days of computers, most language implementations fell into one camp or the other, being either compiled or interpreted. These days, however, many popular scripting languages (such as Perl, Python, and Java) are implemented through a compromise technique where the entire program is initially compiled into an intermediate representation, which is then fed to a runtime engine that accepts and executes it a chunk at a time. In effect, such languages are compiled, then interpreted. AppleScript works this way.
Like those other scripting languages, AppleScript code is compiled into bytecode , meaning that, roughly speaking, the nouns and verbs of the original text are translated into a sort of compressed, coded equivalent, called tokens . These tokens are meaningful to the AppleScript scripting component's runtime engine (and illegible to everyone else). The runtime engine interprets the bytecode, parsing whatever tokens it meets along its path of execution, accumulating them into chunks, and translating these chunks further, as necessary, in order to execute them.
There is sometimes a prejudice against interpreted languages as being slow. It is true that the compiled code must be processed further while being run before it can really be run, but this need not make the language particularly slow—no one complains, for example, that Perl is slow. The AppleScript runtime engine, however, probably does run a good deal slower than it should. Whether you'll perceive this slowness in practice depends on the nature of the script and on the speed of your computer; with today's fast computers, the observable bottleneck will typically be the time required to send Apple events to the target application and for that application to respond, more than the overall speed of the AppleScript runtime engine. (Tips for improving script speed appear in Chapter 22.)
The AppleScript compiler is what's called a single-pass compiler; this is a fairly simple-minded approach to compilation, but it helps to ensure that your script has a certain level of legality and overall consistency before runtime. (Of course, even a legal, successfully compiled script could still choke at runtime, but this would be for a different kind of reason; you'll see many examples over the course of this book.) Consequently, the runtime engine has less work to do, and is therefore smaller and faster, than if AppleScript were not compiled at all.
Also, the use of compilation makes AppleScript a better language. For instance, the following AppleScript code is legal:
sayHowdy( )
on sayHowdy( )
display dialog "Howdy"
end sayHowdy
In this code, we call a handler, sayHowdy( ), before we've defined it. If AppleScript code were