What the *bleep* is IDL doing: COMPILE_OPT

If you are a modern IDL programmer, the line compile_opt idl2 is at the top of every function/procedure/method/$MAIN program you write.  If it's not, I'm here to convince you it should be. 

First off, what exactly is a compile_opt. A compile_opt is a statement which is processed by the IDL compiler to change the behavior of the compiler.  It is processed in order of the statements (meaning if you put a compile_opt in the middle of your code, it's effect would only apply to code after the compile_opt).

What does compile_opt idl2 do?  The idl2 flag sets two flags for the IDL compiler, DEFINT32 and STRICTARR.  DEFINT32 sets the default size of IDL integers to be 32-bits rather than 16-bits.  This is useful because it aligns the default behavior of IDL with the standard size of a C language long, so you can rely on the more liberal -2147483648 and 2147483647 underflow/overflow values of type long.  STRICTARR  prevents IDL from using parenthesis for array indexing.

Why is this important?  Consider the following:

       offset = input(0)

       data = input[100] * offset

What is input?  One of the difficulties of untyped languages is the ability to discern the intent of code from a small context.  In this case, input could either be: a function and an array, or an array which is being accessed two different ways (valid syntax without compile_opt idl2).  By always putting compile_opt idl2 at the beginning of every function, this ambiguity is removed.

You might be thinking to yourself, "But I like indexing array's with parenthesis, I'll just stick compile_opt idl2 in any new code I write".  In the words of a once great robot, "DANGER! DANGER, WILL ROBINSON!"  Consider the following:

test22.pro

PRO test22

  resolve_routine, 'a', /either,/compile_full_file

 

  print, 'Answer = ', b('stuff')

 

END

----

a.pro

FUNCTION b, istuff

  COMPILE_OPT idl2, hidden

 

  RETURN, 'b'

END

 

 

FUNCTION a, istuff

  COMPILE_OPT idl2

 

  RETURN, 'a'

END

If you try to run test22, the function b will not be resolved.  This is because the symbols for test22.pro are generated before the resolve_routine and since there is no reference to b it will be treated as a variable.  After the resolve_routine, the compiler will not override the variable type of b for the function.  This problem will also present itself if you sick compile_opt idl2 in the middle of your code.  When IDL gets confused, you lose.

Here are some simple tricks to follow to avoid these pitfalls:

1. Always put compile_opt idl2 at the top of your function/procedure.
2. If your function doesn't have compile_opt idl2, add it!  Worse case, you have to refactor array parenthesis to brackets.  But this simple refactor will reduce headaches down the road by making your code more readable and extensible.
3. If you are working in legacy code (and insist it remain legacy code), be aware if external code is using compile_opt idl2. If it is, double check your function/procedure/variable names to prevent IDL from getting confused.