• Choose a category
• All
• Classic-Fiction

(* in fact things could be very different tomorrow,

but I really can't speak to that issue just now *)

set b to 2 (* this seems a good idea too *)

A comment delimited with comment delimiters may not interrupt a command, nor precede a command on the same line. Neither of these lines will compile:

set a to (* because we feel like it *) 1

(* here's a good idea *) set a to 1

Comment delimiters attempt to be "intelligent." Comments may be nested, in which case the delimiters must match in pairs. Thanks to this rule, you can easily comment out a stretch of script that already contains some comments:

(* outer comment

(* inner comment *)

rest of outer comment *)

A rather weird side effect of this "intelligence" is that quotation marks and vertical bars inside comment delimiters must also match in pairs:

(* "this works fine" and so does |this| *)

If you remove one quotation mark or one vertical bar from inside that comment, the code won't compile.

Single-line comments take precedence over everything (they cause the rest of the line to be ignored, with no attempt at "intelligence"). Thanks to this rule, you can easily comment out comment delimiters. You might wish to do this while testing, as a quick way of effectively removing and restoring some code. Here, the line of code is commented out and is not executed:

(*

set a to 7

*)

Here, the comment delimiters are commented out, so the line of code is executed:

--(*

set a to 7

--*)

But be careful. This code won't even compile:

(* set a to 1 -- and why not? *)

That's because the closing comment delimiter is itself commented out as part of the single-line comment, so the opening comment delimiter is unbalanced.

Abbreviations and Synonyms

Many AppleScript terms permit other terms to be substituted for them. For example, the following expressions are equivalent in pairs, assuming that a and b are defined:

a is less than b

a < b

a is b

a = b

Some terms have a very large number of equivalents. For example, these expressions all amount to the same thing:

a ≤ b

a <= b

a less than or equal b

a is less than or equal to b

a is not greater than b

a isn't greater than b

a does not come after b

a doesn't come after b

To add to the confusion, upon decompilation, AppleScript might substitute one equivalent for another (see "Decompiling" in Chapter 3). So the code in the previous example compiles, but afterwards it looks like this:

a ≤ b

a ≤ b

a is less than or equal to b

a is less than or equal to b

a is not greater than b

a is not greater than b

a does not come after b

a does not come after b

I call terms that are functionally equivalent to one another synonyms . I call terms that are replaced by other terms on decompilation abbreviations .

Code in this book is compiled before being pasted into the page, so you won't see any abbreviations in the book's code examples (except, as here, with the explicit purpose of displaying an abbreviation). In fact, this book does not even list abbreviations, except where I find them particularly handy when typing code. For example, in real life I never type the word application because I know the abbreviation app will do; so I tell you about this abbreviation ("Application" in Chapter 13).

I don't tell you about all synonyms either, and on the whole I try not to use them. I feel that it's good style, and makes your AppleScript code more legible, to adopt just one synonym for each term and stick with it. In general my personal preference is the shortest synonym, but not always; for example, of the following two expressions, I prefer the second:

a ≠ b

a is not b

And in a very small number of cases I do use two synonyms indiscriminately. For example, I'm equally likely to use either of these expressions:

a = b

a is b

To sum up: wherever there are synonyms, I have a favorite (or, in a very small number of cases, a couple of favorites). My favorites are the versions of each term that I tell you about, and they are the ones I use in code.

Blocks

A block is