Expression Language (EL)

This specification benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.

The work reported in this paper has been funded by the following organisations:

This document specifies an abstract openEHR Expression Language (openEHR EL) that provides a syntax counterpart to the expression package in the openEHR Basic Meta-Model (BMM). This may be used within BMM models, to specify archetype rules, Task Planning expressions, in newer versions of GDL, and in decision language expressions.

The intended audience includes:

Prerequisite documents for reading this document include:

Releated documents include:

This specification is in the DEVELOPMENT state. The development version of this document can be found at https://specifications.openehr.org/releases/LANG/latest/EL.html.

The expression language described in this specification is a more powerful language than the original Basic Expression Language (BEL), and is based on the openEHR BMM expression model. It is a major evolution on BEL syntax, and does not use the BEL meta-model.

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

Feedback may be provided on the openEHR languages specifications forum.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the LANG component Change Request tracker.

Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.

The semantic requirements including the usual arithmetic, boolean, and relational operators, functions, logical quantifiers, operator precedence, constant values, and variables. In addition, there is a need to support multi-lingual translations for symbolic variables, in a similar way to the openEHR Archetype Definition Language (ADL2).

The openEHR Expression Language is based on a combination of first-order predicate logic, object-oriented structural concepts and functional computing. It has some similarities with OMG’s OCL (Object Constraint Language). It also draws on the semantics and some of the syntax (particularly agent-related) of the Eiffel Language (ECMA-367). See Sowa (2000), Hein (2002), Kilov & Ross (1994) for an explanation of predicate logic in information modelling.

It is not exactly the same as any of these languages because:

Following the BMM meta-model, EL treats all classical operators as surface syntax for underlying functions available on types. Thus, the '+' operator in the expression total + 1 is resolved to a function call on the type Integer: total.add(1). In a similar way, higher-order operators ranging over collections of items (e.g. for_all) are resolved to calls to functions assumed to be defined on container types (e.g. my_list.for_all(agent (v:T) ))

Key features of EL include:

The assumed execution model of the Expression language is that EL statements are evaluated by an evaluator against a data context, which determines the truth values of the expression(s). The data context is the origin for some or all of the variables mentioned in the expressions, which may be read from and written to. It may concretely be a retrieved data structure, or data via an API call to the EHR, demographics, laboratory system etc.

The data context may be specified in two ways. It may be inferrable from the artefact or computing context in which the EL statements appear, or it may be specified explicitly. In the former case, the EL instance is minimally a value-returning logical proposition such as systolic_pressure > 0, where the declaration of variables or properties such as systolic_pressure are inferred from e.g. a data binding, and any manifest values obey this EL specification. The implicit case is shown below.

In the explicit form, an EL expressions appear within a BMM model definition, or within a context that explicitly imports a BMM model.

In both cases, the result of parsing into computable form for evaluation must result in instance of the BMM EL meta-types.

The syntax style used in EL is inspired by elements of common languages available today, including TypeScript, Kotlin, Java, etc, with divergences to provide a syntax that is more easily readable to non-IT professionals as well as IT professionals.

The lexical style used in EL is a form of so-called 'snake_case' rather than so-called 'CamelCase', in common with other openEHR specifications, but either may be used in real applications. One reason for using snake-case is be to render EL Modules more readable to the non-IT professional. Upper- and lower-case are not formally distinguished, and the use of upper case is a matter of style only, as follows:

Comments are of two styles. For end-of-line commenting, and for creating visual dividing lines, the leader pattern '--' is used. Dividing lines are a longer line (more than three characters), e.g '---------' or a line of (four or more) '=' symbols, i.e. '========'. The latter is useful for multi-level decision tables.

Comment-only lines start with the bar character ('|'). The example below shows both forms.

EL is fully typed, with type definitions being supplied by one or more models, represented in the form of openEHR BMM specification. All operators are assumed to be implemented by and to map to functions defined on types, including operators such as '+' mapping to the function add() defined on primitive types such as Integer. Accordingly, such operators are defined within the BMM as being operator aliases of their implementing function, which is made possible by the BMM meta-types BMM_ROUTINE and descendants.

An important implementation consequence of this approach is that an expression that is parsed to a classic operator-based AST may be evaluated by progressively searching for operator-aliased functions within the model definition, invoking with the arguments found in the AST structure, and returning Results for the next such computation. Of course, use of built-in native types and functions (rather than always dispatching via a BMM) to handle primitive type operators is likely to be used in the interests of efficiency. Function-matching can be implemented by matching the inferred signature of the operator and its argument(s) with functions having both a conformant (not necessarily identical) signature, and the same operator.

Such model definitions will therefore include primitive type definitions, either the openEHR Foundation Types, i.e. primitive types, container types and interval types, or ones that correspond very closely. In the interests of completeness, EL assumes the openEHR Foundation Types, so as to have a minimal basis.

The EL syntax for these is described below.

Literal values are mostly instances of the types declared in the imported models. Assumed literals correspond to the openEHR Foundation and Based types, and are expressed in the openEHR ODIN syntax, with the exception of List<T>, Set<T> and Map<K,V>, which are distinguished in EL with specific types of brackets. The corresponding classes are described in the openEHR Foundation Types specification.

One exception to the above is tuples, which are direct instances of the BMM meta-type BMM_TUPLE. They take the literal form [a, b, c], where a, b, and c are generally of different types.

Symbolic variables are valid within the scope of the routine in which they are declared, and are classified as read-only or writable. Read-only variables include routine parameters and the automatically declared variable Self, and are reprsented by the meta-type EL_READONLY_VARIABLE.

Writable variables include locally declared variables and the automatically declared variable Result and are represented by the BMM meta-type EL_WRITABLE_VARIABLE.

A type may be directly referenced using the syntax {TypeName}. This has the effect of creating an anonymous variable whose value is a read-only instance of the type. This may be equivalently understood as the 'static view'. A type reference can be the scoper of any feature call that is to read-only and is:

This provides a mechanism, common to many programming languages, for access to constants and helper functions without creating instances.

EL predicates are special meta-operators that are used to express tests on runtime object structures.

Delayed routine calls for both functions and procedures may occur as terminals in an EL expression. The evaluation type (eval_type) of an agent is its signature. Syntactically, these take various forms. An agent can be created using a function or procedure visible in the current scope, using the keyword agent. The arguments list may range from empty to full. For a completely empty list, the routine name on its own may be used.

For a partial argument list, ? symbols are used for the non-filled arguments. This generates an agent whose signature corresponds to the remaining open arguments. In the following example, an agent of the signature <[Integer], Coded_term> is generated, which, since the age of 38 years is supplied, may be thought of as a new function called obstetric_risk_38_years().

Theoretically, an agent could be created with all arguments supplied, without the intention of immediate execution, e.g. agent obstetric_risk ('P38Y', 2), which would generate an agent of signature <[],Coded_term>. This could be later executed by simply using the receiver variable or parameter reference in the normal way, in a later expression.

Agents for procedure calls can be created in the same way as described above. In each case, the evaluation type is a signature of the form <[args]>, i.e. having no return type.

The equality operator = in EL is understood as the function equal() defined on the type Any, of which every other class is a descendant. For all primitive value types (types for which use in expressions directly generates values rather than instance references), the semantics are value comparison, while for all other types, the semantics are reference comparison. For non-openEHR models, '=' will normally map to a similarly-named method, e.g. equals().

To obtain value comparison for non-value types, the function Any.is_equal(), which may be redefined in any sub-type, is used.

Primitive operators in EL are the infix or prefix syntax forms of functions available on primitive types. For example, the operator - (minus) is defined on the class Numeric (an inheritance ancestor of the classes Integer, Real etc) as the following:

This means that where the expression 100 - 5 is encountered in EL, what is really invoked is {Integer}.subtract(), specifically 100.subtract(5).

For convenience, the operators for the Numeric and Boolean types from the openEHR Foundation Types are reproduced below.

Expressions using logical operators may thus be written using standard English names or symbols, as in the following.

In addition, some operators are defined on the other primitive types, including the following.

Operator semantics that require further explanation are described below.

In EL, a decision table is a construct that expresses the equivalent logic of a multi-branch construct that returns a single expression as a result. There are two flavours, both familiar to programmers in mainstream languages: the condition chain (i.e. an if/then/else construct) and the case table (i.e. a case statement). The evaluation of both constructs determines which of a number of possible expressions to return as the result, based on the prior evaluation of branch conditions, whose particular form depends on which flavour of construct is used. Both constructs are thus purely functional, i.e. their branches cannot contain statements (i.e. assignments, procedure calls etc), only expressions.