AppleScript is a scripting language devised by Apple Computer, and built into Mac OS. More generally, AppleScript is the word used to designate the Mac OS scripting interface, which is meant to operate in parallel with the graphical user interface.

History

The AppleScript project was an outgrowth of the HyperCard project. HyperCard had an English language–based scripting language called HyperTalk which could be used for embedding logic and behavior into a HyperCard stack. Apple engineers recognized that a similar type of scripting language could be designed to be used with any application, and the AppleScript project was born.

The natural language metaphor

In keeping with the Mac OS tradition of ease-of-use, the AppleScript language is designed on the natural language metaphor, just as the graphical user interface is designed on the desktop metaphor. Thus, the concept of an object hierarchy is expressed using nested prepositional phrases:

 pixel 7 of row 3 of TIFF image "my bitmap" 

which in another programming language might be expressed as sequential function calls:

 getTIFF("my bitmap").getRow(3).getPixel(7); 

Interapplication communication

AppleScript was designed to be primarily used as a scripting language to control other applications. As such, it depends on the Mac OS interapplication communication protocol called AppleEvents, in particular the AppleEvent Object Model. AppleScript uses an application dictionary to associate the AppleEvents with human-readable terms, thus allowing the translation back and forth between human-readable AppleScript and bytecode AppleEvents. To discover what elements of a program are scriptable, dictionaries for supported applications may be viewed. (In the XCode and Script Editor applications, this is under File → Open Dictionary.)

To designate which application is meant to be the target of such a message, AppleScript uses a "tell" construct:

 tell application "Microsoft Word" to quit 

AppleScript on its own

AppleScript need not depend on other applications. For very simple tasks, AppleScript can be used for self-contained applets. For instance, the code:

 set pix to 72 set answer to text returned of (display dialog "Enter in the number of inches" default answer "1") display dialog answer & "in = " & (answer * pix) & "px" 

Brings up a dialog box requesting a number of inches from the user. This number is then converted to pixels on a system that uses 72 pixels per inch. A second dialog box is brought up displaying the result.

The problem with this is that, unlike other scripting languages like Perl, AppleScript is very poor in built-in facilities, so such scripts are of limited usefulness and often run quite slowly. The main power of AppleScript derives crucially from its ability to orchestrate the abilities of scriptable applications.

AppleScript Studio

With Mac OS X, AppleScript has grown well beyond its humble beginnings. AppleScript Studio is a development environment, which comes free with Mac OS X, which uses AppleScript as the primary programming language, in conjunction with the Cocoa-based ProjectBuilder framework used to construct graphical user interfaces.

With Mac OS X 10.3 ("Panther") AppleScript Studio and ProjectBuilder have been rolled into the XCode integrated development environment. AppleScript Studio lets you build a user interface in a drag-and-drop fashion (similar to Visual Basic) and then "run" the user interface to see what the forms and menus looks like.

Panther also comes with Script Editor, which is a minimalist editor for compiling and running AppleScripts. A nice feature of this editor is that if you right_click (command_click) on the editing area you get a pop_up menu with a large range of options for script fragments to paste into your code. This is an excellent feature for people learning to write AppleScript. From that menu you can also open up the directory where these scripts are kept, and have a look at them. You can also add your own scripts (although you need to restart Script Editor for these changes to show up in the pop up menu. Using these features, you can turn Script Editor into a minimalist, but extensible, Java IDE, for example.

AppleScript dialects

For a short time, AppleScript supported the idea of multiple dialects, which included French, Japanese (kanji), Japanese (romaji), and Italian. Terminology was made available for each dialect, such that the AppleScript compiler could compile and decompile scripts written in any dialect to any other dialect. While the project was a technical success, few application developers provided terminology in multiple languages, and technical support and testing proved to be far too much effort for the very little return on investment. Support for multiple dialects was dropped by Apple in Mac OS 8.5.

AppleScript language essentials

• basic data types are string, integer, real, list, record and object
  • different types can coexist in a list, including nested lists
  • records are lists of key-value pairs
• standard control flow with if / else constructions and repeat loops
• variables are instantiated when used, and are not strictly typed
• script objects can encapsulate methods and data
• script objects can inherit behavior from a parent script
• 'tell' contruct used to identify target of message
• applications can define terminology at runtime
• runtime compiling possible using 'run script' construct
• persistence possible using 'store script' and 'load script'

Applets and Droplets

It was possible to save an AppleScript script as an executable file or applet. If the script had a run handler:

 on run ... end run 

then this would be invoked when the user double-clicked the applet.

If, furthermore, the script had an open handler:

 on open of SomeItems .... end open 

then the applet became a droplet: if the user dragged and dropped some filesystem items on the executable, it would be launched and the open handler would be invoked with a list of references to those items.

Open Scripting Architecture

An important aspect of the AppleScript implementation was the Open Scripting Architecture (OSA). Apple did not want to antagonize the vendors of existing third-party scripting/automation products such as QuicKeys and UserLand Frontier, so it created the OSA as a way for these other languages to be handled on an equal status with AppleScript. Thus, AppleScript was implemented as a scripting component, and the basic specs for interfacing such components to the OSA were public, allowing other developers to add their own such components to the system. Public client APIs for loading, saving and compiling scripts would work the same for all such components, which also meant that applets and droplets could hold scripts in any of those scripting languages.

One of the most interesting features of the architecture, the ability to write language syntax extensions, also turned out to be a significant liability of the language. Because an extension (called an OSAX) could change the basic grammar of AppleScript, it became difficult to predict how the AppleScript compiler would behave. Indeed, one of the most common complaints about AppleScript is the complexity of its syntax. However, the basic language independent of these extensions is quite simple and comparable to the complexity of other programming languages, while retaining its natural language metaphor.

See also

• Sal Soghoian — AppleScript product manager
• William Cook (http://www.cs.utexas.edu/users/wcook/), Donn Denman, Warren Harris, Kurt Piersol — AppleScript designers

External links

• http://www.apple.com/applescript/
• http://www.applescriptsourcebook.com/
• http://www.macscripter.net/