First the given key is looked up, if this fails, the value
at the given position is looked up, and if this also fails,
the default value is returned.
Positional addressing is only valid, as long,
as no value was provided by an explicit key
in the list before the entry in question.
The interface to access table values looks like:
call aot_get_val(val, errCode, L, thandle, key, pos, default).
Position pos and key are both optional, but one of them has to be provided.
If both are provided the key takes precedence over the pos, and the pos
will only be tried if the access to the key fails.
See for example get_table_real() for a more detailed
description of the parameters.
Note that positional addressing only works intuitively as long as there
have been no entries specified by keys in the table.
This kind of resembles the behavior of Fortran interfaces with named or
unnamed arguments, as soon as you provide a name, all following arguments
have to be given by key also.
Just stick to this rule for the Lua tables as well to avoid too much
The reason for this is, that positional addressing in Lua refers only to
the unnamed entries of the tables.
Nodes of different colours represent the following:
Solid arrows point from a procedure to one which it calls. Dashed
arrows point from an interface to procedures which implement that interface.
This could include the module procedures in a generic interface or the
implementation in a submodule of an interface in a parent module.