6.5. The Format of the OPTIONS clause

The format of the OPTIONS clause is very simple, it is followed by
any REXX string expression, which is interpreted as a set of space
separated words. The words are treated strictly in order from left
to right, and each word can change zero or more extension
settings.

Each extension has a name. If the word being treated matches that
name, that extension will be turned on. However, if the word being
treated matches the name of an extension but has the prefix NO,
then that extension is turned off. If the word does not match any
extensions, then it is simply ignored, without creating any errors
or raising any conditions.

Example: Extensions changing parsing

An example of the same is the UPPER instruction. In the following
piece of code the same clause is interpreted in two completely
different ways:

     options ‘NOUPPER’
     do i=1 to 2
          if i=2 then options ‘UPPER’
          upper foo bar
     end

In the first iteration of the loop, the clause starting with the
token UPPER will be a command, issuing the string resulting from
evaluating the expression upper foo bar. However, in the second
iteration of the loop, the same clause is interpreted as an UPPER
instruction. Since these two statements has very different syntax,
it seems impossible to handle both in the same program.  Regina
tries to handle this by “allowing” both syntaxes when parsing the
source code, and selecting the right one when interpreting the
statement in question.

Regina’s frequent usage of extensions may slow down execution. To
illustrate how this can happen, consider the OPEN() extra built-in
function. As this is an extension, it might be dynamically
included and excluded from the scope of currently defined
function.  Thus, if the function is used in a loop, it might be in
the scope during the first iteration, but not the second. Thus,
Regina can not cache anything relating to this function, since the
cached information may be outdated later. As a consequence, Regina
must look up the function in the table of functions for each
invocation. To avoid this, you can set the extension CACHEEXT,
which tells Regina to cache info whenever possible, without
regards to whether this may render useless later executions of
OPTIONS.



 PREV   NEXT