A number of terms that are common in connection with AppleScript are used in a somewhat bewildering variety of senses. The word “script” is particularly liable to be tossed loosely about. This is unfortunate, especially since some of the meanings of “script” are important and rather technical. It’s not a word one can do completely without, and so it is all the more crucial that its meaning not be blurred. This section tries to clarify the main ways in which the word “script” is used.
To “script” an application is to automate it, to drive it, to target it. People say, “I’d like to script the Finder to rename some files automatically.” There is an implication that the Finder already has the power to do things to files, and that we are merely taking advantage of this power by dictating programmatically a sequence of actions that Finder should take.
This sense of “script” is formalized in the way some sources define a " scripting language.” This quotation comes from the ECMAScript Language Specification (http://www.ecma-international.org/publications/standards/ECMA-262.htm):
A scripting language is a programming language that is used to manipulate, customise, and automate the facilities of an existing system. In such systems, useful functionality is already available through a user interface, and the scripting language is a mechanism for exposing that functionality to program control. In this way, the existing system is said to provide a host environment of objects and facilities, which completes the capabilities of the scripting language.
That is a perfect description of AppleScript. It has few powers of its own; it is meant primarily for controlling the powers of existing applications.
A scripting language is intended for use by both professional and nonprofessional programmers. To accommodate non-professional programmers, some aspects of the language may be somewhat less strict.
This leap is common enough, but in my view it is unwarranted. Most languages that are commonly referred to as scripting languages are full-fledged programming languages, and make no particular concession to informality or inexperience. There is arguably nothing easy, and certainly nothing simplistic, about Tcl, Perl, or Scheme. As far as ease of use is concerned, any distinction between a scripting language and a programming language is a distinction without a difference.
Unfortunately this false distinction has played a major role in the history of AppleScript. To this day, Apple’s main web page on AppleScript (http://www.apple.com/applescript/) leaps through extraordinary verbal hoops to avoid the word “program,” which never appears. AppleScript can make “script files,” it can “think,” it can “automate,” it’s something you “use.” The term “script” has ended up as an acceptable synonym for the politically incorrect “program.” You do not program with AppleScript; you script with it. What you write are not programs; they’re scripts. You’re not a programmer; you’re a scripter. This, I feel, is silly. AppleScript is a programming language (and, I happen to think, not a particularly easy one). You are a programmer, and you will write programs with AppleScript.
There is a rigorous sense in
which it is right to speak of an AppleScript program as a script. To
understand what that sense is, you need first to be aware that many
AppleScript programs that you write or read will contain the term
script used to demarcate part of their code.
Here’s an example:
script myScript display dialog "Hello from " & (get my name) & "!" end script run myScript -- dialog says: Hello from myScript!
Such a section of code is often called a script object, but the AppleScript language itself calls it a script.
Now, the interesting thing is that an AppleScript program as a whole is itself a script object. This may sound confusing, but in fact it’s quite a cool and sophisticated aspect of AppleScript. Thus it is reasonable to speak of an AppleScript program as a whole as a script, not as a way of avoiding the fact that it is a program, but as a way of expressing its ontological status within the world of AppleScript. As you’ll learn later, a script as a whole and a script object within a script have exactly the same ontological status. The script-as-a-whole does have some special features of its own, because it is the ultimate container of any other script objects; it is the top-level script object. But it is not different in kind from script objects that it may contain. So it is a “script,” as any script object that it contains is also a “script.” We’ll fully explore the details of script objects later in the book, especially in Chapter 9.
In a completely technical and rigorous sense, the term “script” refers to a unit of operation between a frontend program that asks for some AppleScript code to be compiled or executed and the scripting component that does the actual work. When such a program sends the scripting component a bunch of text for compilation, as in Figure 4-2, that bunch of text is assigned an identifying number. This number points to the code that is being remembered by the scripting component, and is called its script ID . It is by this arrangement that the frontend program and the scripting component can continue to talk about the script while it persists over time, as described earlier in this chapter (Section 4.2.4). The code itself, the thing being remembered by the scripting component, is thus technically a script, because that’s what the scripting component itself calls it. A script is a kind of entity that the scripting component holds on to and can perform various operations on, such as compiling it or executing it.
The individual code file is an important and meaningful unit in AppleScript. Unlike some programming environments, where multiple files are assembled through a “make” or some other build process into a complete program, with AppleScript the individual file is the complete program. An AppleScript program and the file containing it are thus coterminous. But, as we have just seen, an AppleScript program is a script. Therefore it is natural to speak of the file in which your code is saved as itself a script. The script file icon in the Finder seems to represent the script. One says, “Double-click the script to open it in the Script Editor.” The Script Editor itself speaks of saving your code as a script.