Discussing the potential code verification complication when COBOL 2002 User Defined Functions are implemented as CALL BY REFERENCE. This allow functions to modify arguments of arithmetic expressions, breaking rules of the commutative properties of addition (and other concise order of operations verifiability). …
Well met,
Through its 50 year history, COBOL has proven itself as a highly predictable programming language. There are few side effects to ever worry about, and code that is being read can be trusted to give consistent results over millions of runs.
That may change a little, and possibly a lot if care and attention are not paid.
The Draft spec for COBOL 20xx, includes FUNCTION-ID user defined functions.
COBOL is by and large and by design, a static allocation language, movement of data a predictable event.
The functional paradigm changes that predictability. With PROGRAM-ID procedural COBOL
COMPUTE a = b + c END-COMPUTE
COMPUTE a = c + b END-COMPUTE
shares mathematical addition's property of being commutative. The two above statements are equivalent.
Adding in FUNCTION-ID (with arguments passed BY REFERENCE, meaning changeable allowing for side-effect) that property is broken.
COMPUTE a = FUNCTION F(b, c) + FUNCTION G(b, c) END-COMPUTE
is not equivalent to
COMPUTE a = FUNCTION G(b, c) + FUNCTION F(b, c) END-COMPUTE
as function F or G may modify either b or c so the commutative properties of the math cannot be trusted. The first access to G can modify the value that would be the result of F, so it becomes dependent on position in the expression and not commutative.
COBOL programmers using these new features are going to have to think long and hard about the financial calculations used to run the world if there are functional side effects in the mix. FUNCTION-ID is a very, very powerful addition to COBOL. It will require some discipline to ensure that power is not wielded in areas that may lower the level of trust in production systems.
Cheers,
Brian
