The COMPILE_OPT statement; you should use it!

The COMPILE_OPT statement alters IDL’s compile-time behavior. The statement is locally scoped; i.e., it changes IDL’s behavior only within the routine in which it is declared. I use the IDL2 option (a shorthand for the DEFINT32 and STRICTARR options) in all new procedures, functions and methods I write. The DEFINT32 option makes the default IDL integer long (32-bit signed) instead of short (16-bit signed). This is a compatibility measure: it brings IDL into line with just about every other programming language. For example, by IDL's default typing rules, the variable A is a short integer:

IDL> a = 30000 + 10000
IDL> help, a
A               INT       =   -25536

After setting the DEFINT32 option, the same statement produces a long integer:

IDL> compile_opt defint32
IDL> a = 30000 + 10000
IDL> help, a
A               LONG      =        40000

Note that, as a helpful side effect, the use of long integers lessens the chance of an integer overflow. (But why wasn’t A coerced into being a long integer in the first place? This will be a topic for a future post, I promise.) The STRICTARR option enforces the use of square brackets for subscripting. This is an efficiency measure: although you can subscript arrays with parentheses, this creates an ambiguity with respect to function calls, which IDL must disambiguate. For example, is the following statement a function call or an array subscripting operation?

IDL> x = foo(1)

The answer is: we can't tell without context. When IDL encounters such a statement at runtime, it first assumes "foo" is a function and it uses the calling mechanism to attempt to resolve it. If it can't find a match, it then assumes "foo" is an array and it attempts to subscript it. If "foo" is in fact a function, you’ll need to compile it manually (e.g., with .compile) for IDL to recognize it as such; otherwise, IDL will continue to insist that "foo" is an array. The STRICTARR option is particularly useful for writing ENVI batch mode programs in IDL, when IDL may not know about the ENVI library routines called in a program until runtime. The STRICTARR option also eliminates the need for the FORWARD_FUNCTION statement. A helpful side effect of the STRICTARR option is that it makes it easier to distinguish between functions and arrays when reading an IDL or an ENVI program. Note that the COMPILE_OPT statement should be declared at the beginning of a routine; e.g.:

pro foo
   compile_opt idl2

   ; Do something useful here.
end

Any statements declared before COMPILE_OPT won't be addressed by it. I strongly recommend using the COMPILE_OPT statement with the IDL2 option at a minimum (though STRICTARRSUBS and LOGICAL_PREDICATE are also good choices) in all new code that you write. It may seem like a trifle, but I swear it’s helpful – it’s hard to convey the number of times I’ve seen adding a COMPILE_OPT statement solve a problem in class, in a seminar or in talking with Tech Support (Jim Uba came upon another instance this week). I think these options make IDL better behaved and friendlier for new users. I’m considering pushing to make STRICTARR and DEFINT32 the defaults in IDL, with a preference to allow users to revert to IDL’s original behavior.