TRLC Language Reference Manual, Version 2.9

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "Appendix A: GNU Free Documentation License".
  1. Design Goals
  2. Lexing
    1. Encoding
    2. Whitespace and comments
    3. Identifiers and keywords
    4. Punctuation
    5. Integers
    6. Decimals
    7. Strings
  3. Layout and file structure
  4. Preamble
  5. Metamodel (RSL) files
  6. Described names
  7. Qualified names
  8. Type declarations
    1. Enumerations
    2. Tuples (algebraic data types)
    3. Record declarations
  9. Check Files
  10. Checks
  11. Expressions
  12. Names
  13. Operators
    1. Logical operators
    2. Relational operators and membership tests
    3. Adding operators
    4. Multiplying operators
    5. Highest precedence operators
  14. Quantification
  15. Conditional expressions
  16. TRLC Files
  17. Sections
  18. Record object declarations
  19. Markup strings
  20. Null Values

Design Goals

It is important to have design goals for a language. The design goals of TRLC are:

Lexing

Encoding

All input files are encoded in UTF-8. Passing a file with a different encoding to TRLC results in undefined behaviour.

Implementation Recommendation

It is recommended to try to detect this in an implementation and raise a fatal error; but in the interest of compatibility and sanity an implementation shall not provide a way to switch the encoding (at the command-line or otherwise).

Whitespace and comments

Whitespace is ignored.
Comments are C-Style /* .. */ and C++ style //, and are ignored. The matching for C-style comments is non-greedy.

Identifiers and keywords

Identifiers start with a letter and are followed by letters, numbers, or underscores.
IDENTIFIER ::= [a-zA-Z][a-zA-Z0-9_]*
Examples:
A keyword is an identifier that is one of the following reserved words:

Punctuation

Single character delimiters:
Double character delimiters:
Preference is (obviously) given to longer delimiters if there is ambiguity; i.e. == takes precedence over two = tokens.

Integers

Integers are base 2 (prefixed by 0b), 10, or 16 (prefixed by 0x), and leading zeros are effectively ignored. It is possible to separate digit groups with an underscore for readability. It shall be a lexing error to use digits that do not fit into the base.
INTEGER ::= (0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*
Examples:

Decimals

Decimals are base 10, and leading and trailing zeros are effectively ignored.
DECIMAL ::= [0-9]+(_[0-9]+)*\.[0-9]+(_[0-9]+)*
Examples:

Strings

There are three versions of a string, double quoted, triple single quoted, and triple double quoted:
STRING ::= ("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})
Examples:

Static Semantics

The value of a double quoted string is precisely the characters between the two double quotes, with all instances of the \" escape sequence being replaced with ".
The value of a triple quoted string is the whitespace trimmed string of characters between the triple quotes (including the line breaks), The common whitespace at the beginning of each line (ignoring blank lines) starting at the second is removed. The trailing whitespace on every line is removed. There is no escaping in a triple quoted string.

Layout and file structure

There are three types of files:

Dynamic Semantics

First, all .rsl files are parsed. Then, if no errors are raised, all .check files are parsed. Finally, if no errors are raised, all .trlc files are parsed.
After all files are parsed, references are resolved and user-defined checks are applied.

Implementation Recommendation

It is unspecified how an implementation treats errors in .trlc files, but it is recommended to not stop processing after the first error.

Preamble

All files start with a package indication and an optional import list.
file_preamble ::= package_indicationpackage IDENTIFIER
                  { import_clauseimport IDENTIFIER }

package_indication ::= 'package' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_name

import_clause ::= 'import' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_name

Static Semantics

The package indication defines the "current package".
A package may be imported, in which case its name may be used as the prefix of a qualified_name.
A package may not import itself.

Metamodel (RSL) files

A .rsl file starts with a package declaration and is followed by type declarations.
rsl_file ::= file_preamblepackage_indication { import_clause }
             { type_declaration | check_blockchecks IDENTIFIER { { check_declaration } } }

Static Semantics

A package indication in an .rsl file declares a package. Any given package name may only be declared once globally.
In a .rsl file, a package may not import a package that imports itself, directly or indirectly.
An implementation shall support the following builtin types, that shall be made available for all packages:
A Boolean has two values, false and true.
An Integer is a signed integer, with an implementation defined range. This range shall be at least -1000 to 1000, and this can be infinite.
A Decimal is a signed rational with a power-of-ten denominator, with an implementation defined range. This range for the numerator shall be at least -1000 to 1000, and denominator is always a natural number with a range of at least 1 to 1000. Any of these ranges can be infinite (but the denominator is always non-negative).
A String is a sequence of implementation defined characters. (The decision to support Unicode or not is left unspecified.) The maximum length of a String, if any, is implementation defined, but shall be at least 1000.
A Markup_String is identical to a String, except for a few additional constraints on the string contents. Any value of type Markup_String is a valid instance of String, but not the other way around.
A package also includes a number of builtin functions that are made available:
A package also makes available a number of numeric type conversion functions:

Described names

described_name ::= IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_name [ STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})_description ]

Static Semantics

A described name names an entity. The optional string description has no static or dynamic semantics.
Two described names are considered equal if their names are equal.
The description has no bearing on equality. The string description should be exported to the API, so that downstream tools can make use of it. This way we don't have to give some comments special meaning, and we don't have to implement error-prone heuristics in downstream tools for discovering these descriptions.

Qualified names

qualified_name ::= [ IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_package_name '.' ] IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_name

Static Semantics

The package name of a qualified name must be the current package or an imported package.
The name must be a valid symbol in the current scope (if no package is provided) or a valid symbol of the indicated package.

Type declarations

type_declaration ::= enumeration_declaration
                   | tuple_declaration
                   | record_declaration

Static Semantics

It is an error to create a type with a name that is already visible. (Note: this especially includes shadowing one of the builtin types, but also means you cannot shadow packages.)

Enumerations

enumeration_declaration ::= 'enum' described_nameIDENTIFIER [ STRING ]
                            '{' { enumeration_literal_specificationdescribed_name } '}'

enumeration_literal_specification ::= described_nameIDENTIFIER [ STRING ]

Static Semantics

Each described name declares an enumeration literal specification, which shall have a unique name in that enumeration.
It is not an error to have the same literal specification for different enumerations.
It is not an error to have an enumeration literal with the same name as a record or enumeration - as there is no ambiguity - but it is recommended that an implementation emits a warning in this case.
It is an error to specify an (empty) enumeration without any literals.

Example

enum ASIL {
  QM "Not safety relevant"
  A B C D
}

enum My_Boolean {
  yes
  no
  file_not_found
}

Tuples (algebraic data types)

tuple_declaration ::= 'tuple' described_nameIDENTIFIER [ STRING ]
                      '{' field_declarationdescribed_name [ optional ] qualified_name
                      { [ separator_declarationseparator separator_symbol ] field_declarationdescribed_name [ optional ] qualified_name }
                      '}'

field_declaration ::= described_nameIDENTIFIER [ STRING ] [ 'optional' ] qualified_name[ IDENTIFIER . ] IDENTIFIER_FIELD_TYPE

separator_declaration ::= 'separator' separator_symbolIDENTIFIER | @ | : | ;

separator_symbol ::= IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*
                   | '@'
                   | ':'
                   | ';'

Static Semantics

A field type names any valid visible and complete type. (Specifically you may not have a recursive tuple reference.)
A tuple type shall declare separators between all fields, or none of them.
A tuple type with separators may not contain fields that have tuple types with separators. (This is to avoid parsing ambiguities for values such as 1; 2; 3.)
Only tuples with separators may use optional fields. Tuples without separators cannot have optional fields.
After an optional field has been declared, all fields following it must also be optional.
It is an error to declare two fields with the same name in the same tuple. (Note that it is possible, but a bad idea, to have a separator with the same identifier as a field.)

Implementation Recommendation

There is a potential source of ambiguity between tuples with two or more integers separated by a x or b. This is resolved by giving precedence to the lexer. For example the string 0x123 should yield the hex integer 291; but the string 0 x123 or 0 x 123 will generate the tuple. It is recommended to warn when building tuples where a b or x separator follows an integer.

Example

tuple Coordinate {
   x Decimal
   y Decimal
}
// allows you to write (4, 3)

tuple Codebeamer_Item {
   item             Integer
   separator @
   version optional Integer
}
// allows you to write 12345@42 but also just 12345

tuple Doors_Item {
   module_id Integer
   separator :
   item_id   Integer
   separator @
   baseline optional Decimal
}
// allows you to write 0xdeadbeef: 666@1.0 or 0xC0ffee: 1234

Record declarations

record_declaration ::= [ inheritance_qualifierabstract | final ] 'type' described_nameIDENTIFIER [ STRING ]
                       [ 'extends' qualified_name[ IDENTIFIER . ] IDENTIFIER_ROOT_TYPE ]
                       '{' { component_declaration | component_freezingfreeze IDENTIFIER = value }
                       '}'

inheritance_qualifier ::= 'abstract'
                        | 'final'

component_declaration ::= described_nameIDENTIFIER [ STRING ] [ 'optional' ]
                          qualified_name[ IDENTIFIER . ] IDENTIFIER_COMPONENT_TYPE [ array_declaration[ INTEGER .. * ] | [ INTEGER .. INTEGER ] ]

array_declaration ::= '[' INTEGER(0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*_lower '..' '*' ']'
                    | '[' INTEGER(0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*_lower '..' INTEGER(0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*_upper ']'

component_freezing ::= 'freeze' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_component '=' value

Static Semantics

The root type for a record extension must be a valid record type.
A record may be marked abstract, in which case no objects of this type may be declared. It must be extended (even if that extension is empty) before instances of that type can be declared. (Note that it is possible to have components of an abstract type.)
A record may be marked final, and the extension of a final type is also considered to be final (even if it is not explicitly marked as such). An extension of a final type may not contain any component declarations.
Each component declaration shall have a unique name in that record declaration, or any of its root types. (Two separate record extensions may defined the same component, and they may even have different types. But you cannot re-define a component from a parent type.)
Each component type shall refer to a valid type, or to the name of the record type itself. It is an error to refer to a type that has not been declared yet. (As there are no forward declarations in the language, this forces the user type hierarchy to be a DAG, but permitting self-references.)
A component with an array declaration introduces an anonymous array type. This means the type of the record component is not the type as specified, but rather an array where the element type is that type.
It is an error to specify an upper bound that is less than the lower bound. (Note that it is permitted for them to be equal.)
Any valid previously declared record component may be frozen, providing a value of the correct type for the given field in all instances of the record type. It is an error to freeze a component that is already frozen.

Dynamic Semantics

Arrays are indexed by natural numbers and the first index is 0.
An instance of an array shall not have fewer elements than its lower bound.
An array type has no upper bound if * is specified. An array instance for an array type with an upper bound shall not have more elements than its upper bound.
An implementation may impose an arbitrary limit to the actual upper bound of an array (that is treat the * as if it was that limit). This limit, if it exists, shall be greater than or equal to 1000.
A record type that extends another inherits all components, user defined checks, and component freezes specified for its root type.
Instances of an extension may be provided as a reference where a root type is required; but not the other way around. (This provide a limited form of polymorphism, but with the Liskov substitution principle guaranteed.)

Implementation Recommendation

It is recommended to emit a warning on array types with an upper bound of zero.
It is recommended to emit a warning on array types with an upper bound of one.
It is recommended to emit a warning on freezing a component declared in the same record.
It is recommended that an implementation checks if a record type contains a tuple with a identifier separator that is the same as one of its components. While this is not an error (parsing for values is greedy) it is still highly confusing.

Example

abstract type Base_Requirement {
  summary "A short summary of the requirement."
    String

  description "The actual requirement text."
    String
}

type Requirement extends Base_Requirement {
  asil         optional ASIL
  derived_from optional Requirement [1 .. *]
}

final type Supplier_Requirement extends Requirement {
  supplier_id Integer
}

type ACME_Requirement extends Supplier_Requirement {
  freeze supplier_id = 666
  freeze asil        = ASIL.QM
}

Check Files

A .check file is simply a set of check blocks.
check_file ::= file_preamblepackage_indication { import_clause }
               { check_blockchecks IDENTIFIER { { check_declaration } } }

Static Semantics

It is an error to indicate a package that has not been declared in an .rsl file.
A check file may not import any packages.

Implementation Recommendation

Check files are a deprecated feature that allows you to specify checks separate from type declarations. While this seems like a good idea at first, in a large project this can create confusion: consider a global definition for your requirement type stored in a central place which everyone is supposed to use. In this example some random user can create in their sub-project a check file that applies to the global definitions, causing hassle for everyone. It is recommended that an implementation suggests moving any check from a .check file into the package .rsl file.

Checks

check_block ::= 'checks' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_record_or_tuple_name
                '{' { check_declaration } '}'

check_declaration ::= expression ','
                      [ severitywarning | error | fatal ] STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})_message
                      [ ',' STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})_details ]
                      [ ',' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_component_name ]

severity ::= 'warning'
           | 'error'
           | 'fatal'

Static Semantics

It is an error to refer to a type that does not exist in the current package, or is not a record or tuple type.
In a check declaration or expression, it is an error to refer to a component name (or field name) that does not belong to the record (or tuple respectively) indicated.
It is an error to include a newline in the message.
Note that it is never possible to add checks to a type from a foreign package. In check files this is more obvious as you cannot have an import clause, but this is also true for checks declared in .rsl files since it is not possible to specify a qualified name.

Dynamic Semantics

Each check inside a check block is evaluated in the specified order.
If multiple check blocks are declared for the same type, then the order of evaluation of each check block is unspecified.
For record extensions, all checks for the base record must be evaluated before any check of the record extension is evaluated.
If the evaluated expression is true, no action is taken. If it is false, then a diagnostic is emitted with the specified message and details. It is implementation defined if and how the details are shown, for example in a "brief" mode they could be omitted.
The severity, if provided, controls how future errors are treated, and how the TRLC implementation terminates.
The intended meaning of the message is a short description of what is wrong. The intended meaning for the optional details is a longer explanation, including perhaps on what to fix.
The component name (if specified) is a hint where the message should be anchored. It is implementation defined how or if this is taken into account. A suitable anchoring for a message without a component or field could be the object declaration itself. If only a single component or field is used in the expression then the message could be anchored the same way as if the component was indicated explicitly in the check.
It is an important design goal to keep the type system sane and following LSP. I.e. each subtype may only narrow the values permitted in a type. This means for a record R and its extension RE; any valid instance of RE is always a valid instance of R if a new binding of R is created considering only the components that are in R. It will never be possible to delete, suppress, widen, or omit checks in record extensions.

Example

checks Requirement {
  len(description) < 10,
    warning "Description is too short",
    description

  derived_from != null or top_level == true,
    error "Requirement linkage incorrect",
    '''You must set either top_level to true or
             link this requirement to at least one
             other requirement using derived_from.'''


}

checks OverflowGuard {
  value >= -100, fatal "Value must be at least -100"
  value <= 100,  fatal "Value must be at most 100"
  // These bound value, and effectively guard against integer
  // overflow in the below expression

  value ** 2 == 25, warning "Value is not 5 or -5"
}

checks Codebeamer_Item {
  item >= 1, error "CB Item must be positive", item
  version != null implies version >= 1,
    error "CB Version must be positive", version
}

Expressions

expression ::= relation { 'and' relation }
             | relation { 'or' relation }
             | relation [ 'xor' relation ]
             | relation [ 'implies' relation ]

relation ::= simple_expression[ adding_operator ] term { adding_operator term } [ comparison_operator== | != | < | <= | > | >= simple_expression[ adding_operator ] term { adding_operator term } ]
           | simple_expression[ adding_operator ] term { adding_operator term } [ 'not' ] 'in' membership_choicesimple_expression .. simple_expression
           | simple_expression[ adding_operator ] term { adding_operator term } [ 'not' ] 'in' simple_expression[ adding_operator ] term { adding_operator term }

membership_choice ::= simple_expression[ adding_operator ] term { adding_operator term } '..' simple_expression[ adding_operator ] term { adding_operator term }

simple_expression ::= [ adding_operator+ | - ]
                      termfactor { multiplying_operator factor } { adding_operator+ | - termfactor { multiplying_operator factor } }

term ::= factorprimary [ ** primary ] | not primary | abs primary { multiplying_operator* | / | % factorprimary [ ** primary ] | not primary | abs primary }

factor ::= primary [ '**' primary ]
         | 'not' primary
         | 'abs' primary

primary ::= INTEGER(0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*
          | DECIMAL[0-9]+(_[0-9]+)*\.[0-9]+(_[0-9]+)*
          | STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})
          | 'true'
          | 'false'
          | 'null'
          | name
          | '(' expression ')'
          | '(' quantified_expressionquantifier IDENTIFIER in IDENTIFIER => expression ')'
          | '(' conditional_expression ')'

Implementation Recommendation

The parsing of unary minus can be confusing: -a % b is actually - (a % b). The semantics of % are carefully specified so that this does not matter. It does also mean that -a / -b is not legal and needs to be written as either -a / (-b) or even better (-a) / (-b). It is recommended that a linter warns whenever a unary minus is encountered that has a non-trivial term or factor as its operand.

Example

checks Expression_Examples {
  asil != ASIL.QM, "must be safety related"

  len(summary) + len(description) > 10, "too short"

  description != null implies "potato" in description,
    "description must mention the best vegetable"

  (forall item in codebeamer_link => item > 50000),
    warning "cb link is suspiciously small"
}

Names

A name can be one of 5 things:
name ::= qualified_name[ IDENTIFIER . ] IDENTIFIER
       | name '.' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*
       | name '[' expression ']'
       | name '(' parameter_listexpression { , expression } ')'

parameter_list ::= expression { ',' expression }

Static Semantics

The qualified_name must resolve to record component or tuple field in scope, or a visible record object, or a visible enumeration type.
If the prefix of a dot (.) access resolves to an enumeration type, then the identifier must be a valid literal of that type. If the prefix of a dot (.) access resolves to a tuple, then the identifier must be a valid field of the type of that tuple. Any other prefix is an error.
The type of the name in an array indexing prefix (i.e. [ .. ]) must be an array type.
The name in a function call must resolve to one of the builtin functions.
The builtin function len is of arity 1. Its parameter must be of type String or an array type. Its return type is Integer.
The builtin functions startswith and endswith are of arity 2. All of their parameters must be of type String. The return type of either function is Boolean.
The builtin function matches is of arity 2. Its parameters must be of type String. The return type is Boolean. The second parameter must be a valid regular expression. (It is implementation defined which regular expression language is used, but it is highly, _highly_ recommended to implement the standard POSIX regular expressions.)
In addition, the second parameter to the matches function must be a static compile-time constant, i.e. it must not depend on the value of a record field or the value of a quantified variable.
The numeric type conversion functions are of arity 1 and polymorphic (they are defined for both integer and rationals). They return the type indicated by the function name. (They are polymorphic in case we want to introduce a true rational type, or a floating point type.)

Dynamic Semantics

The len function computes the length of the given string or array.
The startswith function returns true iff the first parameter fully contains the second parameter at its start.
The endswith function returns true iff the first parameter fully contains the second parameter at its end.
The matches function returns true iff the first parameter is matched by the regular expression given in the second parameter.
The Integer type conversion rounds to the nearest integral, away from zero in the case of ties.
The Decimal type conversion simply converts the given integer to the exact same rational.

Name resolution

Name resolution is case sensitive.

Example

checks Name_Examples {
  foo, "foo"
  // names the record field foo

  len(field) > 0, "foo"
  // name that is a function call

  potato[3] < potato[2], "foo"
  // name that is an array index

  Decimal(potato[0]) < wibble, "foo"
  // note that type conversion is necessary

  cb_link.item >= 50000, warning "cb item value is oddly low"
  // you can obtain a tuple's values
}

Operators

comparison_operator ::= '=='
                      | '!='
                      | '<'
                      | '<='
                      | '>'
                      | '>='

adding_operator ::= '+'
                  | '-'

multiplying_operator ::= '*'
                       | '/'
                       | '%'

Static Semantics

For a chain of operators of the same category, the association is left to right.

Dynamic Semantics

It is implementation defined if type checks (range or length) are performed for intermediate values; if type checks are not performed then the resulting expression must not be an error.
This means you either type check all the time, or you guarantee that any intermediate will not create an error in the implementation, as long as the final value fits in the relevant type. For example if A and B are maximum length Strings, then "potato" in A + B may either create an error when attempting to concatenate the strings, OR it must work correctly. What you cannot do is cause undefined behaviour in the evaluation.

Logical operators

Static Semantics

There are five Boolean operators defined (not, and, or, xor, implies) for expressions of Boolean type. The type of the result is Boolean.

Dynamic Semantics

Operators with short-cut semantics are and, or, and implies. They first evaluate their left-hand side and proceed to evaluate the right-hand side if it could influence the final result. The semantics of these operators are the usual ones.
Operators with standard semantics are xor, and not. They do the usual thing.

Relational operators and membership tests

Static Semantics

The equality operators == and != are defined for all types, as long as the types are compatible, i.e. they are the same types or one type is a (transitive) record extension of the other. The result is a Boolean.
The ordering relations <, <=, >=, and > are defined for pairs of integers or pairs of rationals only. The result is a Boolean.
Range membership tests not in and in are defined for integers and rationals only. All operands must have the same type, and the result is a Boolean.
Substring tests not in and in are defined for Strings only. The result is a Boolean.
Array membership tests not in and in are defined for all arrays. The type of the left-hand side must match the element type of the array. The result is a Boolean.

Dynamic Semantics

Null is only equal to itself.
Two tuple instances are equal if they both contain the same values for all their components.
Two record references are equal if they both refer to the same record.
Two arrays are equal if they both have the same length and items (in the same order).
The meaning of the relationship operators are the usual.
An inclusive range membership test x in a .. b has the same meaning as the Boolean expression x >= a and x <= b. (This means if a is less than b, it is not an error. Instead the result of such a test is always false.)
An exclusive range membership test x not in a .. b has the same meaning as the Boolean expression x < a or x > b.
The meaning of the substring test is the usual. Note that the substring test is of course performed on the value of the string, not the original literal.
The array membership test X in A is equivalent to (exists item in A => item == X). The array non-membership test X not in A is equivalent to (forall item in A => item != X).

Adding operators

Static Semantics

The binary adding operator + is defined for integers, rationals, and strings. The binary subtraction operator - is defined for only integers and rationals.
When + is used to concatenate strings, the result is always a String, even if one or both operands if of type Markup_String. (This means the only way you can create a markup string is when you construct it at record object declaration.)
The unary adding operator +, and the unary subtraction operator - is defined only for integers and rationals.
For binary adding operators the types of the operands have to match, and the result is the same type as the two operands. For unary adding operators the result is always the same as the operand.

Dynamic Semantics

The definition of + and - for integers and rationals is the usual one.
The definition of + for strings is string concatenation.

Multiplying operators

Static Semantics

The multiplying operators *, / are defined for integers and rational types. The remainder operator % is defined for integers only. For any of these the result is always the same type as the operands.

Dynamic Semantics

The definition of * is the usual one.
The definition of / for integers is floor division. (For example 5 / 2 is 2 and -5 / 2 is -3.)
The definition of / for rationals is the usual one.
The modulus division for x % y satisfies the relation x = y*N + (x % y), for some (signed) value of N, with one of the following constraints met:
Division by zero or modulo division by 0 is an error.

Highest precedence operators

Static Semantics

The exponentiation operator ** is defined for integers and rational bases, and returns the same type as its base. The exponent type is always an Integer.
The right-hand side parameter of ** must be a static compile-time constant, i.e. it must not depend on the value of a record field or the value of a quantified variable. It must not be negative.
The absolute value prefix operator abs is defined for integers and rationals, and returns a (positive) integer or rational respectively.
The logical negation prefix operator not is defined for Booleans only, and returns a Boolean.
The definition of exponentiation ** is the usual one.
The definition of absolute value abs is the usual one.
The definition of logical negation not is the usual one.

Quantification

quantified_expression ::= quantifierforall | exists IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_name 'in' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_component_name '=>'
                          expression_PREDICATE

quantifier ::= 'forall'
             | 'exists'

Name resolution

The component name must be defined in the current record, and must be an array type.

Static Semantics

A quantified expression introduces a new name, that is valid only inside the predicate. This new name must not shadow any other. (This means two separate quantified expressions may use the same name, but you may not nest and shadow, and you may not shadow a component name either.)
The type of the predicate must be Boolean. The result of a quantified expression is Boolean.

Dynamic Semantics

During evaluation of the quantified expression, each element of the array is evaluated in sequence and its value is bound to the declared name. The predicated is then evaluated with this binding.
For universal (forall) quantification the final value is true iff all predicates evaluate to true. (This means universal quantification over an empty array is vacuously true.)
For existential (exists) quantification the final value is true iff the predicate evaluate to true at least once. (This means existential quantification over an empty array is vacuously false.)

Implementation Recommendation

In general Quantification is equivalent to a chain of and or or expressions, however it is left unspecified if quantification is using short-circuit semantics or not. It is recommended (for sanity) to do the following:

Conditional expressions

conditional_expression ::= 'if' expression_CONDITION 'then' expression_DEPENDENT
                           { 'elsif' expression_CONDITION 'then' expression_DEPENDENT }
                           'else' expression_DEPENDENT

Static Semantics

The condition expressions must be of Boolean type. The dependent expressions must all be of the same type, and the type of the entire conditional expression is also of that type.

Dynamic Semantics

Each condition is evaluated in sequence. Evaluation stops on the first condition that evaluates to true; after which the corresponding dependent expression is evaluated and returned.
If all conditions are evaluated to false, then the else dependent expression is evaluated and returned.

TRLC Files

A .trlc file is simply a set of record object declarations.
trlc_file ::= file_preamblepackage_indication { import_clause }
              { trlc_entrysection_declaration | record_object_declaration }

trlc_entry ::= section_declarationsection STRING { { trlc_entry } }
             | record_object_declaration

Static Semantics

It is permitted to indicate a package that has not been declared in an .rsl file, in which case it is declared by the package_indication in the .trlc file. Such a package is declared late. If two .trlc files declare the same package, then it is unspecified which file actually declares it.
For TRLC files it is impossible fully parse a file in isolation, since we must process at least the package indication of every other trlc file to know which import statements are valid.

Sections

A section has no semantic impact, and no impact on name resolution. Section names do not have to be unique. It may be exposed in an API, for example to section a HTML view of requirements.
section_declaration ::= 'section' STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})_section_name
                        '{' { trlc_entrysection_declaration | record_object_declaration } '}'

Record object declarations

record_object_declaration ::= qualified_name[ IDENTIFIER . ] IDENTIFIER_RECORD_TYPE IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_object_name
                              '{' { component_associationIDENTIFIER = value } '}'

component_association ::= IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_component_name '=' value

value ::= [ adding_operator+ | - ] INTEGER(0[xb])?[0-9a-fA-F]+(_[0-9a-fA-F]+)*
        | [ adding_operator+ | - ] DECIMAL[0-9]+(_[0-9]+)*\.[0-9]+(_[0-9]+)*
        | STRING("([^"\n]|(\"))*")|('{3}.*?'{3})|("{3}.*?"{3})
        | qualified_name[ IDENTIFIER . ] IDENTIFIER_RECORD_OBJECT
        | qualified_name[ IDENTIFIER . ] IDENTIFIER_ENUM_TYPE '.' IDENTIFIER[a-zA-Z][a-zA-Z0-9_]*_enumeration_literal
        | '[' [ value { ',' value } ] ']'
        | tuple_aggregate

tuple_aggregate ::= '(' value { ',' value } ')'
                  | value { separator_symbolIDENTIFIER | @ | : | ; value }

Static Semantics

The type of the declaration must be a valid, non-abstract record type. If no qualified name is given, the record type must be in the indicated package. (Note that it is not legal to declare a tuple object.)
The name of the declaration must be a unique name and sufficiently distinct in the current package. (See name resolution for a definition of sufficiently distinct.) The name of the declaration must not shadow a type name or package.
Each component name must be a valid, non-frozen component of the record type. It is an error to attempt to assign to a frozen component (even if the value assigned would be the same value as it's frozen value).
Each enumeration must be a valid enumeration type in the indicated (or qualified) package. Each enumeration literal must be a valid literal of the indicated enumeration in the prefix.
The type of each value must match each component or array element type. Records are specified through references (there is no way to specify an inline anonymous instance).
It is an error to not provide a value for a non-optional component.
The aggregate of a tuple must use the correct form. A tuple without separators uses the bracket syntax (e.g. (1, 2, 3), and a tuple with separators must use the separator syntax (e.g. 12345@42).
A tuple value for a tuple without separators must contain one value, in order, for each of its fields.
A tuple value for a tuple with separators must contain the separator symbols as indicated in the type, in order. Optional fields and their preceding separator may be omitted. Once an optional field has been omitted, all following (optional) fields must also be omitted.

Dynamic Semantics

A record object declaration creates a new binding for a record. The value of any frozen components is the value provided in the freezing declaration. After references are resolved, all applicable checks on the object, including any checks for tuples, are evaluated in the context of this binding.
It is an error to refer to a record by name that does not exist. It is legal to refer to an record that has not been encountered yet, as references are resolved after parsing.
A record reference must match in type, i.e. be of the correct type or any record extension of that type. (For example if RE extends R, then a list of R may contain references to instances of R and RE. A list of RE may not contain any references to R.)

Static Semantics

The checks for a tuple aggregate are immediately evaluated after the last value is parsed.

Name resolution

When declaring record objects there are wider rules that indicate name clashes. Specifically a record may not be declared if its "simplified name" clashes with any other "simplified name". A "simplified name" is the name converted to lowercase and all underscored removed.
For example the simplified name of Foo_Bar is foobar and therefore it clashes with Foobar, F_Oobar, or Foo_B_A_R. But only at record declaration; when referring to other object you still have to use a precise match.
The purpose of this rule is to avoid requirements that have hard to distinguish names.

Implementation Recommendation

When exposing record instances through the API, it is required to make the type of the instance available. There are some alternatives, none of which are required:

Example

Requirement Potato {
  description = "Hello World!"
  coordinate = (42.0, 666.0)
  derived_from_cb = [
    1234,     // references codebeamer item 1234 (at head revision)
    1900@42   // references codebeamer item 1900 at version 42
  ]
}

Markup strings

A Markup_String allows you to inline references to TRLC record in a string. The format is limited and simple: any name or comma-separated list of names enclosed in double square brackets (i.e. [[ and ]]) is considered a reference.
Attempting to nest, or close a list that does not exist, or not close an open list before the end of the string is an error.

Static Semantics

The fragment of BNF grammar applicable is qualified_name. The type of each named object must be a record type. (This means you cannot reference types or enumerations.)

Dynamic Semantics

The references are resolved late, just like an ordinary record reference. (This means you can forward-reference objects, or reference yourself.)

Name resolution

The name resolution rules for the qualified_name are exactly the same as they are for any other qualified_name. (This means you need to import all packages from which you reference objects.)

Example

Requirement Bean_Vehicle {
  description = "The car shall have [[WHEEL_COUNT]] wheels."
}

Requirement SW_Process {
  description = "We shall use [[TRLC, LOBSTER]] for achieving software traceability."
}

Constant WHEEL_COUNT {
  value = 3
}

Tool TRLC {
  vendor  = "BMW AG"
  url     = "https://github.com/bmw-software-engineering/trlc/"
  license = License.GPL3
}

Tool LOBSTER {
  vendor  = "BMW AG"
  url     = "https://github.com/bmw-software-engineering/lobster/"
  license = License.AGPL3
}

Null Values

Static Semantics

The literal null value is only permitted to appear in an equality or inequality. Any other context (such as (if a then null else b) is rejected statically.
The expression null == null is statically true.

Dynamic Semantics

The value of an optional component or field that is not specified is null.
For any other operator or operation, the null value is considered out of bounds and raises an error. (This means you can check if something is null or not, but any other use will cause an error.)

Appendix A: GNU Free Documentation License

Version 1.3, 3 November 2008

Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <https://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

The "publisher" means any person or entity that distributes copies of the Document to the public.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/licenses/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Document.

11. RELICENSING

"Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A "Massive Multiauthor Collaboration" (or "MMC") contained in the site means any set of copyrightable works thus published on the MMC site.

"CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.

"Incorporate" means to publish or republish a Document, in whole or in part, as part of another Document.

An MMC is "eligible for relicensing" if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

    Copyright (C)  YEAR  YOUR NAME.
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.3
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with … Texts." line with this:

    with the Invariant Sections being LIST THEIR TITLES, with the
    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.