AppleScript_ The Definitive Guide - Matt Neuburg [167]
As part of the terminology resolution process, AppleScript translates terms into their corresponding four-letter codes and constructs any Apple events that are called for (Chapter 3). So in Example 20-1, the Finder defines folder as 'cfol' and count as 'core\cnte', and AppleScript constructs this Apple event:
core\cnte {
kocl:'cfol',
----:'null'( )
}
The Apple event is written into the compiled code, ready to be sent to the Finder at runtime.
Terminology Clash
Things don't always go smoothly when AppleScript resolves terminology. Terms are sought in the dictionaries of the innermost application, of AppleScript itself, and of all scripting additions, as well as in the script. Given such a large namespace comprising contributions from multiple independent entities, it is possible for conflicts to arise. Such a conflict is called a terminology clash . Either the programmer generates the clash by an unwise choice of variable names, or different dictionaries generate it by defining the same term in different ways.
When the programmer causes a terminology clash, various things can happen. Sometimes the code won't compile; sometimes it won't run; sometimes it runs but gets an unexpected result; sometimes the clash is resolved sensibly and there's no problem.
Compile-time Error
When the compiler stops you from using a term, the term is probably defined elsewhere as a different "part of speech" from how you're trying to use it.
For example, this won't compile:
local count
-- compile-time error: Expected variable name or property but found command name
The term count is defined by AppleScript itself as a command. Thus you're effectively trying to use a verb where a noun is expected.
This won't compile:
set sel to {length:2, offset:4}
-- compile-time error: Expected variable name, class name or property but
found command name
This is similar to the previous example: offset is defined as a command in a scripting addition. Observe that length doesn't cause a clash here, even though it's defined in AppleScript's own dictionary; that's because it's defined as a property, and you're using it as a property (see "Record Properties" in Chapter 13).
This won't compile:
local desktop
-- compile-time error:
--Expected variable name or property but found application constant or consideration
Again, the problem is a scripting addition; desktop is a constant, part of an enumeration used in the path to command. (See "Enumerations," later in this chapter.)
When you don't declare a variable, the error message is different, though the cause is the same:
set desktop to 7 -- compile-time error: Can't set desktop to 7. Access not allowed
A constant isn't something that can be assigned to.
In those examples, the clash was with a term defined by AppleScript or a scripting addition. Within a tell block, the same sort of thing can happen with respect to a term defined by the target application:
tell application "Finder"
set container to 7 -- compile-time error: Can't set «class ctnr» to 7.
Access not allowed
end tell
Within the context of a tell block targeting the Finder, container is resolved as the Finder's term container, which is a class name. A class can't be assigned to.
Here's an example where the error message is particularly unhelpful:
tell application "Finder"
script eject -- compile-time error: Expected "tell", etc. but found "script"
end script
end tell
The cause is that eject is a command defined by the Finder.
One more example. One day I was confused when the filter example at the end of "Handler and Script Object as Parameter" in Chapter 9 refused to compile. The troublesome line was apparently this one:
return filterer's filter(L)
-- compile-time error: Expected expression but found command name
It turned out that a recently installed scripting addition (the Satimage osax) contained a filter command.
Runtime Error
As we've just seen, you can't use the name of a command as a declared variable. If you don't declare it, though, you can get away with using the name