Null Typed Objects

Objects that have the Null type play a special role in the execution of clauses in functions. The result of this special role is that Null typed objects like the null object, the Exception object, the Return object, and the Break object play a major roll in the "flow of control" in the execution of code in the Sym language.

Functions return null if none of the clauses generate a result. Allowing functions to return null would normally require adding testing for null. For example, in the clause:

if "b" is 3, then in the first expression in the ElseList on the right-hand side, the IntegerEvaluate call returns null. But we don't want the clause to return the expression Power[a, null]. We want the processing to fall through to the second clause in this case.

In the build process (the right-hand side of a clause) if we build an expression and one of the terms is null, then the whole expression becomes null. So in the example where b = 3, the entire first clause in the ElseList evaluates to null instead of the expression Power[a, null].

The same is true for the second clause - if "b" is a number that's not an integer, then the integer evaluate returns null, so the Power term becomes null and the Mult term also becomes null.

The same thing is true for any other object that has the Null type. For example, both the Break objects and the Exception objects behave in the same way as the null object when we are building an expression in a clause. The only difference is that if, for example, the IntegerEvaluate returned a Break or an Exception object, that object would be returned as the result for the ElseList, the processing of the ElseList won't fall through to the next clause for any object other than null.