Conditional creation of code by the parser
This functionality does not run in MATLAB.
%if condition1 then casetrue1 elif condition2 then casetrue2 elif condition3 then casetrue3 ... else casefalse end_if
%if controls the creation of code by the parser depending on a condition.
This statement is one of the more esoteric features of MuPAD®. It is not executed at run time by the MuPAD interpreter. It controls the creation of code for the interpreter by the parser.
%if may be used to create different versions of a library which share a common code basis, or to insert debugging code which should not appear in the release version.
If the condition yields TRUE, the statement sequence casetrue is the code that is created by the parser for the %if-statement. The rest of the statement is ignored by the parser, no code is created for it.
If the condition yields FALSE, then the condition of the next elif-part if evaluated and the parser continues as before.
If all conditions evaluate to FALSE and no more elif-parts exist, the parser inserts the code of the statement sequence casefalse as the code for the %if-statement. If no casefalse exists, NIL is produced.
The whole statement sequence is read by the parser and must be syntactically correct. Also the parts that do not result in code must be syntactically correct.
Note that instead of end_if, one may also simply use the keyword end.
In case of an empty statement sequence, the parser creates NIL as code.
Note: The conditions are parsed in the lexical context where they occur, but are evaluated by the parser in the context where the parser is executed. This is the case because the environment where the conditions are exically bound simply does not exist during parsing. Thus, one must ensure that names in the conditions do not conflict with names of local variables or arguments in the surrounding lexical context. The parser does not check this!
No function exists in the interpreter which can execute the %if-statement. The reason is that the statement is implemented by the parser, not by the interpreter.
In the following example, we create debugging code in a procedure depending on the value of the global identifier DEBUG.
Note that this example is somewhat academic, as the function prog::trace is a much more elegant way to trace a procedure during debugging.
DEBUG := TRUE: p := proc(x) begin %if DEBUG = TRUE then print("entering p") end; x^2 end_proc: p(2)
When we look at p, we see that only the print command was inserted by the parser:
proc(x) name p; begin print("entering p"); x^2 end_proc
Now we set DEBUG to FALSE and parse the procedure again to create the release version. No debug output is printed:
DEBUG := FALSE: p := proc(x) begin %if DEBUG = TRUE then print("entering p") end; x^2 end_proc: p(2)
If we look at the procedure we see that NIL was inserted for the %if-statement:
proc(x) name p; begin NIL; x^2 end_proc
A Boolean expression
A statement sequence
A statement sequence
This statement may remind C programmers of conditional compilation. In C, this is implemented by a pre-processor which is run before the parser. In MuPAD, such a pre-processor does not exist. The %if-statement is part of the parsing process.