The specification says, that variables are declared when they are first used, and that if a variable is used before it is assigned a value, then its value is NULL.
Currently Arden2ByteCode purposely checks for usage of undefined variables and shows an error at compile-time. This is helpful, as using a variable, before it holds a value is usually a user-error and not what is intended, e.g. a mistyped variable name.
The INCLUDE statement allows pulling variable definitions from other MLMs at runtime:
other_mlm := MLM 'other_mlm';
INCLUDE other_mlm;
p := NEW Patient WITH "John Doe"; // Patient object is defined in other_mlm
This only works for special variables:
- MLM
- event
- interface
- object
- resource (≥v2.6)
As shown above, the Patient object definition is not known at compile-time. Supporting the INCLUDE statement, is therefore at odds with using undefined variable checks at compile-time.
There are multiple approaches to this problem:
- Let checks only apply to normal variables, not special variables. Special variables can not be used in normal expressions (e.g.
5 + other_mlm), as this leads to a compile-time error. This doesn't work for event variables though, as they can be used like booleans (IF my_event THEN …).
- Other MLMs are included at compile-time, like in C
#include directives. This is a bit awkward as MLMs may be called at run-time and therefore need to be present at compile-time and runtime. It also doesn't mix well with Javas classloading concept which allows loading (MLM-)classes at runtime.
- Undefined variables return
NULL. This is more conforming to the specification. Undefined variable checks could still apply as long as no INCLUDE statement has occurred before. Checks could also be deactivated via a command line flag.
The specification says, that variables are declared when they are first used, and that if a variable is used before it is assigned a value, then its value is
NULL.Currently Arden2ByteCode purposely checks for usage of undefined variables and shows an error at compile-time. This is helpful, as using a variable, before it holds a value is usually a user-error and not what is intended, e.g. a mistyped variable name.
The
INCLUDEstatement allows pulling variable definitions from other MLMs at runtime:This only works for special variables:
As shown above, the
Patientobject definition is not known at compile-time. Supporting theINCLUDEstatement, is therefore at odds with using undefined variable checks at compile-time.There are multiple approaches to this problem:
5 + other_mlm), as this leads to a compile-time error. This doesn't work for event variables though, as they can be used like booleans (IF my_event THEN …).#includedirectives. This is a bit awkward as MLMs may be called at run-time and therefore need to be present at compile-time and runtime. It also doesn't mix well with Javas classloading concept which allows loading (MLM-)classes at runtime.NULL. This is more conforming to the specification. Undefined variable checks could still apply as long as noINCLUDEstatement has occurred before. Checks could also be deactivated via a command line flag.