ESL0006 - Domains¶
| Field | Value |
|---|---|
| Author(s) | T. Wilschut |
| Reviewer(s) | A.T. Hofkamp, T.J.L. Schuijbroek |
| Status | Final |
| Type | Standard (S) |
| Created | 13-12-2019 |
| Finalized | t.b.d. |
Warning
This LEP's syntax enhancement is written using an EBNF syntax as opposed to the current PEG syntax since it was finalized before the switch.
Abstract¶
In ESL0001 behavior requirements and constraints have been introduced which gave raise to the need of being able the verify whether a specification is complete over the full range of stimuli. Such functionality requires more precise specification of the domain of variables.
In this LEP, a syntax extension is proposed that enables users to define a domain for each variable type. All variables inherit the domain of their type. This is a first step in enabling completeness checks.
Motivation¶
In ESL0001 behavior requirements and constraints have been introduced which gave raise to the need of being able the verify whether a specification is complete over the full range of stimuli. Such functionality requires more precise specification of the domain of variables. The current implicit domain of \((-\infty, \infty)\) for integers and reals is insufficient, as no flow in any real system is ever near \(\pm\infty\). The implicit domain of any sequence of characters for strings does not suffice either. Similarly, feasibility studies require clearly defined domains. Therefore, this LEP proposed a syntax extension that enables users to explicitly define domains for variable types, which is a first step in enabling completeness checks and feasibility studies.
Rationale¶
Semantically a type denotes the kind of values that a variable of that type can assume. For example, a real number. A domain denotes the set of possible values that a variable of a certain type may take. For example, all non-negative real values. In math, the domain of continuous data is usually indicated by lower and upper boundaries. For discontinuous data enumerations are often used that list the set of possible values. Constants are typically used to define data that can only assume a single value. In this LEP, we add such functionality to ESL.
Intervals¶
The domain of continuous data may be defined by a closed interval, an open interval or multiple disjunct intervals. It is proposed to define closed intervals in the following manner:
That is, the definition of a type is extended with a lower and upper bound. In this case, a variable
of type foo can only assume real values of at least 0.0 and at most 10.0. By omitting either the
lower or upper bound one can create an open interval. For example:
indicates that variables of type faa can assume real values of at least 0.0. One can define two
disjunct open intervals by using an or construct. For example:
indicates that a variable of type fuu can assume real values of at most 0.0 or least 10.0. In
general, the or construct can be used to define multiple (open) intervals. For example:
indicates that a variable of type fee can assume real values of at least -1.0 and at most 0.0 or
at least 10.0 and at most 20.0 or at least 100.0. In other words, the domain of a variable of type
fee is defined by two closed and one open interval that are disjunct.
Note
An interval spanned by domain boundaries is different from an interval spanned by a set of design-requirements or constraints. An interval spanned by domain boundaries indicates all possible values that exist while an interval spanned by a set of design-requirements or constraints denotes all values that are desired or feasible. Therefore, an interval spanned by a set of design-requirements or constraints with respect to a certain variable must overlap with the interval spanned by domain boundaries of the type of that variable. Otherwise, the design space is infeasible.
Interval checking¶
The ESL compiler checks for empty intervals, overlapping intervals and inconsistencies in sub-intervals. For example:
yields an empty interval as no value can satisfy the lower and upper bound. This is not allowed and
yields an error. Since this implies that no value exists for all variables of type feo within a
specification. As such, by definition, the specification spans an infeasible design space.
Overlapping domains yield a warning. For example:
defines an overlapping domain as any real value of at least 0.0 and at most 10.0 satisfies the lower and upper bounds.
Inconsistencies in intervals yield an error. For example,
yields an error as the interval defined for foi is not a sub-interval of its parent domain feu.
Interval checking¶
The ESL compiler checks for empty intervals, overlapping intervals and inconsistencies in sub-interval. For example:
yields an empty interval as no value can satisfy the lower and upper bound. This is not allowed and
yields an error. Since this implies that no value exists for all variables of type feo within a
specification. As such, by definition, the specification spans an infeasible design space.
Overlapping domains yield a warning. For example:
defines an overlapping domain as any real value of at least 0.0 and at most 10.0 satisfies the lower and upper bounds.
Inconsistencies in intervals yield an error. For example,
yields an error as the interval defined for foi is not a sub-interval of its parent domain feu.
Enumerations¶
The domain of discontinuous data is usually defined by at set of distinct values. Enumerations are added to ESL to define the set of distinct values that a discontinuous variable may take. For example:
indicates that a variable of type fii may assume a value of red, blue, 1 or 2. The values
of an enumeration may have heterogenous types.
Constants¶
Constants are defined by assigning a distinct value to a variable type. For example:
implies that all variables of type gravitational-constant have a real value of 9.81.
Units¶
By default the implicit [-] unit is assumed for all values in domain boundaries, enumerations and
constants. However, as explained in ESL0003, in feasibility studies units are
required to verify whether a comparison between a variable and a literal value, or between two
variables makes any sense. Such a verification remains impossible of no units are attached to the
values within the domain of a variable. That is, an upper bound of 10 m/s is different from an upper
bound of 10 km/s. Therefore, units can be specified after the values used within domain boundaries,
enumerations and constants.
For example, the following listing shows several good and bad examples of how to define units within domain boundaries:
That is, first one has to define a type that represents the physical quantity of interest and its
allowed units. Here being speed with units m/s and km/h. Subsequently, one can define types
that represent subdomains of type speed. For instance, types human-speed, car-speed and
boat-speed denote subdomains of type speed. Here boat-speed will yield an error as the used
unit knots is not allowed for the physical quantity speed. Type air-speed will yield an error
as well as the build in type real has the default [-] unit.
Similarly, one can specify units after values used within constants. For example, in the following
listing the physical quantity acceleration is defined with unit m/s^2. The type
gravitational-constant represents the value of 9.81 m/s^2 within the acceleration domain.
Enumerations are slightly different as the values within an enumeration may be heterogenous in type and therefore do not span a sub-domain of a parent type. As such, the unit of a value may be specified directly after the value. For example:
Specification¶
The LEP introduces new syntax for the definition of domain boundaries, enumerations and constants.
These additions effect the type-definition section syntax as shown in the following listing:
where enumeration-specification and range-specification are the two major additions. The
enumeration-specification allows one to define arbitrary combinations of values as explained in
the Enumerations section. A range-specification consists of an
interval-specification or an constant-specification. The interval-specification syntax enables
on the define multiple (open) intervals. The constant-specification syntax enables one to define a
constant. As explained in Intervals and Constants, respectively.
Backwards Compatibility¶
Domain specifications are optional. Therefore no compatibility issues are expected.
Proof of concept¶
The section will be added once the syntax modifications have been implemented.
Rejected ideas¶
The following ideas where rejected.
Ranges¶
In certain situations one may want to define a domain that only contains the even numbers between 1 and 90. In such a case, it becomes elaborate to enumerate all allowed values. In programming language ranges are usually used to define such a sequence. In ESL could, for example, be defined as:
However, this is for the time being considered to be too 'techy' for ESL. Therefore, it is currently not implemented.
Type unions and intersections¶
With the addition of domains variable types become sets of variables. As such, one may want to define new types based on the union or intersection of existing types. However, this is for the time being considered to be too 'techy' for ESL. Therefore, it is currently not implemented.
Open issues¶
Please see the Open Issues section of ESL0003.