ESL0006 - Domains

LEP

ESL0006

Author(s)

  1. Wilschut

Reviewer(s)

A.T. Hofkamp, T.J.L. Schuijbroek

Status

Accepted

Type

Standard (S)

Created

13-12-2019

Finalized

date

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:

1
2
define type
  foo is a real of at least 0.0 and at most 10.0

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:

1
2
define type
  faa is a real of at least 0.0

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:

1
2
define type
  fuu is a real of at most 0.0 or at least 10.0

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:

1
2
define type
  fee is a real 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

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:

1
2
define type
  feo is a real of at least 10.0 and at most 9.0 # ERROR, empty domain.

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:

1
2
3
define type
  fea is a real of at least 0.0 and at most 6.0 or at least 4.0 and at most 10.0
  # WARNING, overlapping domains.

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,

1
2
3
define type
  feu is a real of at least 0.0 and at most 6.0
  foi is a feu of at least 7.0 and at most 8.0 # ERROR, infeasible sub-interval

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:

1
2
define type
  feo is a real of at least 10.0 and at most 9.0 # ERROR, empty domain.

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:

1
2
3
define type
  fea is a real of at least 0.0 and at most 6.0 or at least 4.0 and at most 10.0
  # WARNING, overlapping domains.

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,

1
2
3
define type
  feu is a real of at least 0.0 and at most 6.0
  foi is a feu of at least 7.0 and at most 8.0 # ERROR, infeasible sub-interval

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:

1
2
define type
  fii is an enumeration of red, blue, 1, 2

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:

1
2
define type
  gravitational-constant is a real equal to 9.81

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 LEP-0003, 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:

1
2
3
4
5
6
define type
  speed is a real with units m/s, km/h
  human-speed is a speed of at least 0.0 [m/s] and at most 10 [m/s]  # Ok
  car-speed is a speed of at least 0.0 [km/h] and at most 220 [km/h] # Ok
  boat-speed is a speed of at least 0.0 [knots] and at most 20.0 [knots] # ERROR,  unit not allowed.
  air-speed is a real of at least 0.0 [km/h] and at most 960.1 [km/h] # ERROR, unit not allowed.

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.

1
2
3
define type
  acceleration is a real with unit m/s^2
  gravitational-constant is an acceleration equal to 9.81 [m/s^2]

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:

1
2
define type
   engine-outputs is an enumeration of 10 [Nm], 20 [Nm], 30 [Nm]

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 type-definition ::=
     "define" "type" \n
   { new-type-name \n }+

 new-type-name ::=
     TYPE-NAME
   | TYPE-NAME "is" "an" enumeration-specification
   | TYPE-NAME "is" ( "a" | "an" ) TYPE-NAME
       [ unit-specification | range-specification ]

 unit-specification ::=
     "with" ( "unit" | "units" ) UNIT { "," UNIT }

 enumeration-specification ::=
    "enumeration" "of" VALUE [ "["  UNIT "]" ] { "," VALUE [ "["  UNIT "]" ]}

 range-specification ::=
     ( interval-specification | constant-specification )

 interval-specification ::=
    "of" interval { "or" interval }

 interval ::=
     ( open-interval | closed-interval )

 open-interval ::=
     ( lower-bound | upper-bound )

 closed-interval ::=
     lower-bound "and" upper-bound

 lower-bound ::=
     "at" "least" VALUE [ "["  UNIT "]" ]

 upper-bound ::=
     "at" "most" VALUE [ "["  UNIT "]" ]

 constant-specification ::=
     "equal" "to" VALUE [ "["  UNIT "]" ]

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:

1
2
define type
  foo is a real from 2 to 90 with step size 2

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 - Units.