The names and types an expression may refer to, known before it runs.

Feel.prepare/2 uses a scope to resolve names, to match names that contain spaces or operator characters, and to check calls and infer types. A scope has these parts:

• names - the variables, with the type of each value they will be bound to. A function is a variable whose type is a function type.
• types - the type names an expression may use, such as the item definitions of a DMN model.
• allowed_values - for some variables, the values they may have, as the source text of a list of unary tests, as in the allowedValues of a DMN item definition ("[0..150]", ""a", "b"", "< 100"). See below.
• constraints - the allowed values and type constraints for variables and their members, with key steps through contexts and :each through lists (:type_constraints in new/2).
• result_type and result_allowed_values - what the expression gives: the type of its result, and the values it may have. They are the typeRef and the allowedValues of the variable of a DMN decision.

Allowed values

The bound value of a variable with allowed values is verified when a run starts (D-138), for the variables that the expression reads: a value that none of the tests accepts is replaced by null, with a :value_not_allowed error, and null itself is exempt. The tests are tested against the value as ?, and may use the other names of the scope. They are read when an expression that uses the variable is prepared, and a test that cannot be read is an error of that expression, with the code :invalid_allowed_values. Their source is kept as it is written, since a scope is data; Feel.Analysis.AllowedValues compiles it.

A variable declared as a list ({:list, :number}) has the tests applied to each element, as the allowedValues of a DMN item definition with isCollection are (D-51): "[0..10]" for list<number> means that every element, other than null, is in [0..10]. The first element that is not makes the whole value null, with an error that says which. So are the allowed values of the result, when its result_type is a list (D-138).

Type constraints, and the members of a value

The typeConstraint of a DMN item definition is a list of unary tests like the allowed values, but for the value as a whole: for a list, "count(?) > 0" says the list has an element, where allowed values are for each element. They are given as type_constraints, by the name of the variable. For a value that is not a list the two are the same.

Both can be given for a member of a value, by a subject {name, steps}: the steps are the keys of the context to go down, and :each to go to the elements of a list. {"person", ["age"]} is the age of a person, {"orders", [:each, "total"]} the total of each order. The tests are for the member as the tests of a variable are for the variable, and a member that is not there or is null is exempt. A value with a member that is not allowed is not allowed, as a list with an element that is not (the whole value is null, with an error that says which member). They narrow the type of the member, so person.age is a number in [0..150].

Names that are never null

In the specification null is a value of every type, so a variable declared :number may be null, and so is anything computed from it. A type marked not null ({:non_null, :number}, or "number!" for Feel.Type.parse/2, D-48) says that the variable is never null: with the default declarations: :enforce the analysis types the expression without the null that the variable would bring, and a run ends with an error of the kind :input if the bound value is null, is not bound, cannot be converted to the type, or is not one of its allowed values. This is an extension to standard FEEL: expression type syntax also accepts the mark in function parameters and instance of targets. Preparation currently rejects an outer non-null result declaration with :not_implemented; result constraints are not a guarantee that evaluation cannot return null.

Types the lattice cannot say

The types of the specification have no union and no negation. A name that is anything but a number is {:not, :number} ("Any except number"), and one that is a number or a string is {:union, [:number, :string]} ("number | string"), for Feel.Type.parse/2 (D-178). They are declared like any other type, in the names, the :types, the :result_type and the :input, inside a list or a context, and under the mark: {:non_null, {:union, [:number, :string]}}. null is in them as it is in every declared type, unless the whole is marked. The type of the name in the analysis is the union they make, and with the default declarations: :enforce the run makes it true: a value that is not in it is null with a :type_mismatch error. See Feel.Type.Composite.

The result

The result of the expression is converted to the result_type and has to conform to it, and then it has to satisfy the result_allowed_values (D-138). In DMN this is how a decision gives its value to its variable. A scope is shared by the expressions that see the same names, so the scope of one expression is made with put_result/2 from the scope of the others, which is cheap. The options :result_type and :result_allowed_values of Feel.prepare/2 take the place of those of the scope.

The built-in functions are not stored here; they are always in scope, in the outermost layer, and a name in this scope shadows them.

All names in a scope are canonical (see Feel.Name). new/2 canonicalizes the names it is given. The functions that put and fetch single entries expect canonical names already, since the analyzer gets them from the parser.