In OmniMark, consumption and processing of input data is separated from selecting the source of the input,
      meaning that the input variable does not have to be lexically in scope for you to
      consume it. Instead, any string source or markup source can be placed in an input execution scope. While an input source is in the current input scope, all pattern-matching and
      parsing statements and rules will consume it regardless of the lexical scope they occur in.
    
A new input scope is created by every submit, every variant of scan, and every
      matches test. They establish the current input for the execution scopes contained within them. They
      also initiate scanning of that source. You can change the current input scope without initiating scanning by using
      using input as.
    
Once an input scope is established, it is in effect for the execution scope of the submit,
      scan, or using input as that established it. Within that scope, you can initiate a new
      scan of the current source using #current-input. This allows you to perform efficient one-pass
      scanning of nested structures by initiating a new scan for each level of nesting, without the need to capture the
      whole structure and re-scan it.
    
The following code demonstrates this with the function "sum-of-csv", which calculates the sum of a series of
      comma-separated values found in the current input. This function could be called anywhere there is a current input
      scope, and it will consume a series of comma-separated numeric values from the current input scope and return the
      sum. It will exit as soon as it encounters data that does not fit the pattern it is looking for, leaving the
      current input scope intact, but with the comma-separated-value data consumed. 
define integer function sum-of-csv as local integer sum initial {0} repeat scan #current-input match white-space* digit+ => number white-space* ","? set sum to sum + number again return sum process repeat scan "Results: (12,34,65, 92 , 75 )" match "Results:" white-space* "(" output "Total: " || "d" % sum-of-csv match ")" again
Note the difference between this code and the more common programming practice represented by the following
      program:
define integer function sum read-only integer numbers as local integer total initial {0} repeat over numbers set total to total + numbers again return total process local integer numbers variable repeat scan "Results: (12,34,65, 92 , 75 )" match "Results:" white-space* "(" [digit or space or ","]* => csv ")" repeat scan csv match digit+ => num set new numbers to num match any again output "Total: " || "d" % sum numbers again
The differences between these two pieces of code are twofold. First, in the second, more conventional, code the
      outer level of code is responsible for identifying the whole nested structure. This has a kind of symmetry about
      it, but it is misleading symmetry. The task of recognizing the beginning of a nested structure takes place outside
      the nested structure. (You find the door marked "IN" when you are outside; you find the door marked "OUT" when you
      are inside.) The task of recognizing the end of a nested structure should take place inside the nested structure.
      In our first example, the function that handles the comma-separated values is responsible for figuring out when
      the comma-separated values end. It does this very easily by exiting the repeat scan as soon as it
      sees a character that does not fit the pattern it is looking for. 
    
The second difference between the two programs is that the second program has to scan the csv data twice—once
      when it is trying to find it in the data stream, and again when it is analyzed in the second repeat
        scan. The first program processes the csv data and finds the end of the structure in one pass.