AppleScript_ The Definitive Guide - Matt Neuburg [35]
Tip
Just a reminder: all AppleScript code must be compiled before it can be executed. In a script editor application, if you edit code in a script window and then ask to run the script, the script editor application will attempt to compile it first. AppleScript will refuse to run even a single line of a script if it cannot first compile the whole thing (though the script editor application Smile gives you a way around this, because it permits compilation and execution of individual lines of code in a text window). Code that has already been compiled doesn't have to be compiled again in order to be executed as long as it is not edited. If you edit any of the code in a script, the entire script must be compiled anew before it can be executed.
Decompiling
A curious feature of AppleScript is that it not only compiles scripts, it decompiles them, turning compiled bytecode back into human-readable text. Decompilation is not an unknown procedure in the computer world, but it's usually a kind of hacker tool (used, for example, to steal someone else's code); I don't know any other computer language where decompilation is a routine behavior of the language implementation itself.
AppleScript decompiles on two main occasions: right after you compile a script, and when you open a compiled script file for display in a script editor application. The procedure in both cases is essentially the same. When a compiled script is displayed to a human user, it is pretty-printed, with indentation to reflect the script's structure, and different kinds of word shown in different fonts, sizes, styles, and colors. This pretty-printing , as we have seen, is performed by the AppleScript scripting component, not by the script editor application (the script editor application merely asks the AppleScript component for the pretty-printed script and displays it). The AppleScript scripting component generates the pretty-printed version of the script, not from the original text, but from the compiled bytecode. In other words, in order to generate the pretty-printed text, it decompiles the bytecode.
Tip
The way different kinds of word are formatted for pretty-printing depends upon your formatting preferences . You set these in a script editor application; for example, in Script Editor, you use the Formatting pane of the Preferences window. Your choices here are remembered by the AppleScript scripting component itself, and thus are truly global, affecting all scripts displayed in all script editor applications.
This behavior has some curious consequences. The pretty-printed code that you see when you compile your text in a script editor application is not, you understand, a colorful version of your text; it's a completely different text, supplied by decompiling the compiled script's bytecode. Therefore, some of the words constituting your script may actually differ before and after compilation. For example, suppose you type this code into a script editor application:
tell app "Finder" to get ref disk 1
Compile that code. Now your code is displayed like this:
tell application "Finder" to get a reference to disk 1
The reason is that some AppleScript terms have abbreviations that are acceptable for purposes of compilation, but the scripting component substitutes, at compile time, a token signifying the canonical form of the term; thus, when it decompiles the bytecode, what you see is the canonical form.
AppleScript may even, in the course of decompilation, rebreak your code's lineation. AppleScript allows you to break long lines into shorter lines through the use of a continuation character (¬); at compile time AppleScript will sometimes undo your attempts to use this feature, removing your continuation characters or putting them somewhere else. If I compile this code:
do shell script "echo 'hi'" ¬
password "myPassword"
AppleScript rebreaks it like this:
do shell