The FORWARD_FUNCTION statement causes argument(s) to be interpreted as functions rather than variables (versions of IDL prior to 5.0 used parentheses to declare arrays).
FORWARD_FUNCTION Name1, Name2, ..., Namen
For example, attempting to compile the IDL statement:
A = xyz(1, COLOR=1)
will cause an error if the user-written function XYZ has not been compiled and the filename xyz.pro is not found in the IDL path. IDL reports a syntax error, because xyz is interpreted as an array variable instead of a function name.
This problem can be eliminated by using the FORWARD_FUNCTION statement. This statement has the following syntax:
FORWARD_FUNCTION Name"italic">1, Name"italic">2, ..., Name"italic">N
where Name is the name of a function that has not yet been compiled. Any names declared as forward-defined functions will be interpreted as functions (instead of as variable names) for the duration of the IDL session.
For example, we can resolve the ambiguity in the previous example by adding a FORWARD_FUNCTION definition:
; Define XYZ as the name of a function that has not yet been
; IDL now understands this statement to be a function call instead
; of a bad variable reference.
a = XYZ(1, COLOR=1)
Note: Declaring a function that will be merged into IDL via the LINKIMAGE command with the FORWARD_FUNCTION statement will not have the desired effect. Routines merged via LINKIMAGE are considered by IDL to be built-in routines, and thus need no compilation or declaration. They must, however, be merged with IDL before any routines that call them are compiled.