DMN12 — Missing type names in FEEL functions (user and external)

Currently there are three kind of functions in DMN / FEEL:

• builtin functions (see page 130), strongly typed with optional parameters and var args, with static typing.
• DMN functions defined in the metamodel (see functionDefinition element in xsd schema), strongly typed, with static binding
• FEEL functions defined in FEEL (see grammar rule 57), weakly typed with dynamic typing.

Mixing both static typing and dynamic typing in the same language is not a great idea from the execution point of view.

I am not a fan of dynamic typing mainly because it pushes semantic rules in the dynamic semantics and diminishes the quality of software products (e.g. increases maintenance costs) .

Imagine for example a context that contains an entry x with
function(a, b) a + b
and another one calling
x(1, 2)
The semantic analyzer cannot type check and infer the return type of the definition, it has to wait until the function is invoked. The type of x is partial (unknown parameter types and return types) for the rest of execution.

On top of that the function can be used both for numbers and strings. If the intended behavior changes over time for one use case the user has to write another function anyway.

It gets even harder to handle type checking for external functions.

I suggest adding an a parameter type in rule 58

formal parameter = parameter name ":" type name

where type name is a FEEL type or a complex type (defined via a typeRef)

part of improved types/itemdefinitions

DMN12-216 adds optional types to FEEL functions