AppleScript_ The Definitive Guide - Matt Neuburg [54]
The continuation character appears as the "logical not" sign; it is MacRoman codepoint 194, Unicode (and WinLatin1 and ISOLatin1) codepoint 172. This character is usually typed on Macintosh as Option-L; but as a convenience, in a script editor application, typing Option-Return enters both the logical-not character and a return character, and is the usual way of continuing a line. For example:
set a to ¬
1
It is a compile-time error for anything to follow the continuation character on the same line other than whitespace.
It is a compile-time error for the line following the continuation character to be blank, unless what precedes the continuation character is a complete command, as in this very silly example:
set a to 1 ¬
set b to 2
A continuation character inside a literal string is interpreted as a literal logical-not character. To break a long literal string into multiple code lines for legibility without introducing unwanted return characters into the string, you must concatenate multiple literal strings:
set s to "one very long line " & ¬
"deserves another"
Under some circumstances, AppleScript will move or remove your continuation characters at compile time. There's nothing you can do about this; it's an effect of the decompilation process. See "Decompiling" in Chapter 3.
Tip
In this book, long lines are manually broken for legibility. Continuation characters are inserted to indicate such breaks, without regard for whether AppleScript would move or remove these continuation characters in a compiled version of the script.
Result
At runtime, a line of AppleScript code that actually executes an expression—that is, it isn't blank, a comment, or mere flow control (looping and branching)—will usually generate a result . This result is some sort of value; the particular value depends upon what the line does.
The line need not be a command; any valid AppleScript expression constitutes a valid line, even if it does nothing. For example, this is a valid line of AppleScript code, and it has a value (can you guess what it is?):
5
A line's result may be captured in two ways: explicitly or implicitly. The next two sections describe them both. As you'll see, my view is that in general you should not make any use of the fact that a line of code has a result. However, the exception proves the rule, so I will also suggest that in just one situation (while developing your code) capturing a line's value implicitly is useful.
Explicit Result
The result of a line after it is executed may be captured explicitly by using the keyword result in the next line that is executed. For example:
5
display dialog result 5
One sees this technique used typically after fetching a value in a context of interapplication communication. For example, this is a fairly common style of coding:
tell application "Finder"
get the name of every folder
end tell
set L to the result
Here's another example:
tell application "Finder"
count folders
end tell
set c to the result
Why is this technique so common? It may be a habit derived from HyperTalk , where this was a standard idiom. Or people may feel that a line is more legible and understandable if it consists of a single command. Nonetheless, this technique is unnecessary. You can execute a command and capture its result in the same line by nesting commands, as I mentioned in the previous section:
tell application "Finder"
set L to (get the name of every folder)
set c to count folders
end tell
What's more, using result is, I would argue, a downright bad idea. To use result is to be dependent upon AppleScript's rules about what a statement's result is. But you may not know these rules as clearly as you suppose. Your intuitions can lead you astray. For example:
set L to {"Mannie", "Moe"}
set end of L to "Jack"
After these two lines, L is {"Mannie", "Moe", "Jack"}, but result is "Jack". If you were expecting result to be the same as L, you'll be wrong, and code that depends upon this assumption won't work.