85 lines
3.3 KiB
TeX
85 lines
3.3 KiB
TeX
% Input Data
|
|
|
|
\label{s:indata}
|
|
|
|
\sectiondept{it}
|
|
|
|
The implementation \shall accept input in a manner described by
|
|
\sref{hostenv-qs}.
|
|
|
|
\p{indata} The implementation \shall accept dynamic input data as an
|
|
associative array of values whereby the key represents the name of the input
|
|
parameter and its associated value is a vector of (a)~character strings or
|
|
(b)~an arbitrarily deep array of character strings. An implementation \shall
|
|
support at least a vector of character strings to satisfy condition~(b), but
|
|
\may choose to support a greater depth for implementation-specific data.
|
|
|
|
\p{indata-vscalar} When a scalar is expected, an implementation \shall also
|
|
accept a vector $v$, but \shall recognize only the first index $v_0$ of the
|
|
vector and \shall act as though $v_0$ was the provided scalar.
|
|
|
|
An implementation \shall implicitly return all undefined parameter requests as
|
|
the scalar floating-point value $0.00$. This includes undefined indexes on
|
|
defined parameters as well as undefined indexes on undefined parameters.
|
|
|
|
\p{determ} The implementation \shall be ^[deterministic]---that is, its
|
|
operation \shall be controlled exclusively by its input data and not by external
|
|
state such as the current date or time of day, unless such data are passed as
|
|
input data as defined by \pref{indata}.
|
|
|
|
If an implementation relies on a ^[input data!third-party service] for a
|
|
calculation~$c$, then the implementation is \exempt from the requirements of
|
|
\pref{determ} only so far as is necessary to retrieve the data from the
|
|
third-party service and populate~$c$; no other exemptions are permitted.
|
|
|
|
If multiple arguments are provided for the same ^parameter name, the
|
|
implementation \must fail in error, unless an implementation cannot be aware of
|
|
such a condition.\footnote{As an example, a ^JavaScript object literal with
|
|
duplicate fields does not throw an error, but instead silently drops
|
|
duplicates.}
|
|
|
|
|
|
\index{parameter type|(}
|
|
|
|
\section{Parameter Type Definitions}
|
|
\label{s:paramtypes}
|
|
\sectiondept{it}
|
|
An implementation \may use alternative names for these types, or neglect to
|
|
implement the types at all, so long as the output and error conditions of the
|
|
implementation cannot be distinguished in any way from an implementation that
|
|
does implement the parameter types defined in this section.
|
|
|
|
\begin{ex}
|
|
If a parameter type is simply an ^[parameter type!alias] of another type, an
|
|
implementation may decide to use the corresponding base type. If a parameter
|
|
type is simply a restriction on its base type, an implementation may apply
|
|
such a domain restriction however it sees fit---e.g., a block of conditionals.
|
|
\end{ex}
|
|
|
|
\subsection{Base Parameter Types}
|
|
\sectiondept{it}
|
|
The parameters defined within this section are not derived from any other
|
|
parameter types and are known as \dfn{parameter type!base parameter types}.
|
|
|
|
All other parameter types not defined within this section \shall be derived from
|
|
these base types; such parameters are known as \dfn{parameter type!derived
|
|
parameter types}.
|
|
|
|
\begin{description}
|
|
\typedef core bool:
|
|
Boolean---any datatype able to hold a `yes' or `no' value ($1$ or $0$
|
|
respectively)
|
|
|
|
\typedef core float:
|
|
Single-precision binary floating-point number (as defined by IEEE 754
|
|
binary32)
|
|
|
|
\typedef core int:
|
|
Any signed 32-bit integer
|
|
\end{description}
|
|
|
|
\index{parameter type|)}
|
|
|
|
%% content set with \inputtypes will be outptu at this point
|
|
|