2.2. Null clauses Null clauses are clauses that consist of only whitespace, or comments, or both; in addition to the terminating clause delimiter. These clauses are ignored when interpreting the code, except for one situation: null clauses containing at least one comment is traced when appropriate. Null clauses not containing any comments are ignored in every respect. Example: Tracing comments The tracing of comments may be a major problem, depending on the context. There are basically two strategies for large comments: either box multiple lines as a single comment, or make the text on each line an independent comment, as shown below: trace all /* This is a single, large comment, which spans multiple lines. Such comments are often used at the start of a subroutine or similar, in order to describe both the interface to and the functionality of the function. */ /* This is also a large comment, but it is written as multiple */ /* comments, each on its own line. Thus, this is several clauses */ /* while the comment above is a single comment.*/ During tracing, the first of these will be displayed as one large comment, and during interactive tracing, it will only pause once. The second will be displayed as multiple lines, and will make several pauses during interactive tracing. An interpreter may solve this situation in several ways, the main objective must be to display the comments nicely the to programmer debugging the code. Preferably, the code is shown in a fashion that resembles how it is entered in the file. If a label is multiple defined, the first definition is used and the rest are ignored. Multiple defined labels is not an SYNTAX condition. A null clause is not a statement. In some situations, like after the THEN subclause, only a statement come. If a null clause is provided, then it is ignored, and the next statement is used instead. Consider the following code: parse pull foo if foo=2 then say ‘foo is not 2’ else /* do nothing */ say ‘that”s it’ This will not work the way indentation indicates, since the comment in this example is not a statement. Thus, the ELSE reads beyond the comment, and connects to the SAY instruction which becomes the ELSE part. (That what probably not what the programmer intended.) This code will say that’s it, only when foo is different from 2. A separate instruction, NOP has been provided in order to fill the need that was inadequately attempted filled by the comment in the code fragment above. Example: Trailing comments The effect that comments are not statements can be exploited when documenting the program, and simultaneously making the program faster. Consider the following two loops: sum = 0 do i=1 to 10 /* sum 1 2 3 ... 8 9 10 */ sum = sum + i end sum = 0 do i=1 to 10 sum = sum + i /* sum 1 2 3 ... 8 9 10 */ end In the first loop, there are two clauses, while the second loop contains only one clause, because the comment is appended to an already existing clause. During execution, the interpreter has to spend time ignoring the null clause in the first loop, while the second loop avoids this problem (assuming tracing is unenabled). Thus, the second loop is faster; although only insignificantly faster for small loops. Of course, the comment could have been taken out of the loop, which would be equally fast to the second version above.