The Epsilon Object Language (EOL)

The primary aim of EOL is to provide a reusable set of common model management facilities, atop which task-specific languages can be implemented. However, EOL can also be used as a general-purpose standalone model management language for automating tasks that do not fall into the patterns targeted by task-specific languages. This section presents the syntax and semantics of the language using a combination of abstract syntax diagrams, concrete syntax examples and informal discussion.

Module Organization

In this section the syntax of EOL is presented in a top-down manner. An EOL programs are organized in modules. Each module defines a body and a number of operations. The body is a block of statements that are evaluated when the module is executed[^1]. Each operation defines the kind of objects on which it is applicable (context), a name, a set of parameters and optionally a return type. Modules can also import other modules using import statements and access their operations, as shown in the listing below.

// file imported.eol
operation hello() {
  'Hello world!'.println();
}

// file importer.eol
// We can use relative/absolute paths or platform:/ URIs
import "imported.eol";

hello(); // main body

// ... more operations could be placed here ...
classDiagram
class EolModule {
  +main:StatementBlock
}
class ImportStatement {
  +imported:EolModule
}
class Operation {
  +name: String
  +context: EolType
  +parameters: Parameter[*]
  +returnType: EolType
}
class ExecutableAnnotation {
	+expression: Expression
}
class SimpleAnnotation {
	+values: String[*]
}
EolModule -- ImportStatement: *
EolModule -- Operation: operations *
Operation -- Annotation: annotations *
Operation -- StatementBlock: body
EolModule -- StatementBlock: main
StatementBlock -- Statement: statements *
Annotation <|-- ExecutableAnnotation
Annotation <|-- SimpleAnnotation

User-Defined Operations

In mainstream object oriented languages such as Java and C++, operations are defined inside classes and can be invoked on instances of those classes. EOL on the other hand is not object-oriented in the sense that it does not define classes itself, but nevertheless needs to manage objects of types defined externally to it (e.g. in metamodels). By defining the context-type of an operation explicitly, the operation can be called on instances of the type as if it was natively defined by the type.

For eample, consider the code excerts displayed in the listings below. In the first listing, the operations add1 and add2 are defined in the context of the built-in Integer type, which is specified before their names. Therefore, they can be invoked in line 1 using the 1.add1().add2() expression: the context (the integer 1) will be assigned to the special variable self. On the other hand, in the second listing where no context is defined, they have to be invoked in a nested manner which follows an in-to-out direction instead of the left to right direction used by the former excerpt. As complex model queries often involve invoking multiple properties and operations, this technique is particularly beneficial to the overall readability of the code.

1.add1().add2().println();

operation Integer add1() : Integer {
  return self + 1;
}

operation Integer add2() : Integer {
  return self + 2;
}
add2(add1(1)).println();

operation add1(base : Integer) : Integer {
  return base + 1;
}

operation add2(base : Integer) : Integer {
  return base + 2;
}

EOL supports polymorphic operations using a runtime dispatch mechanism. Multiple operations with the same name and parameters can be defined, each defining a distinct context type. For example, in the listing below, the statement in line 1 invokes the test operation defined in line 4, while the statement in line 2 invokes the test operation defined in line 8.

"1".test();
1.test();

operation String test() {
  (self + " is a string").println();
}

operation Integer test() {
  (self + "is an integer").println();
}

Annotations

EOL supports two types of annotations: simple and executable. A simple annotation specifies a name and a set of String values while an executable annotation specifies a name and an expression. The concrete syntaxes of simple and executable annotations are displayed in the listing below.

// Simple annotation
@name value(,value)

// Executable annotation
$name expression

Several examples for simple annotations are shown the listing below. Examples for executable annotations will be given in the following sections.

@colors red
@colors red, blue
@colors red, blue, green

In stand-alone EOL, annotations are supported only in the context of operations, however as discussed in the sequel, task-specific languages also make use of annotations in their constructs, each with task-specific semantics. EOL operations support three particular annotations: the pre and post executable annotations for specifying pre and post-conditions, and the cached simple annotation, which are discussed below.

Pre/post conditions in user-defined operations

A number of pre and post executable annotations can be attached to EOL operations to specify the pre- and post-conditions of the operation. When an operation is invoked, before its body is evaluated, the expressions of the pre annotations are evaluated. If all of them return true, the body of the operation is executed, otherwise, an error is raised. Similarly, once the body of the operation has been executed, the expressions of the post annotations of the operation are executed to ensure that the operation has had the desired effects. Pre and post annotations can access all the variables in the parent scope, as well as the parameters of the operation and the object on which the operation is invoked (through the self variable). Moreover, in post annotations, the returned value of the operation is accessible through the built-in _result variable. An example of using pre and post conditions in EOL appears below.

1.add(2); 
1.add(-1);

$pre i > 0 
$post _result > self 
operation Integer add(i : Integer) : Integer {
  return self + i;
}

In line 4 the add operation defines a pre-condition stating that the parameter i must be a positive number. In line 5, the operation defines that result of the operation (_result) must be greater than the number on which it was invoked (self). Thus, when executed in the context of the statement in line 1 the operation succeeds, while when executed in the context of the statement in line 2, the pre-condition is not satisfied and an error is raised.

Operation Result Caching

EOL supports caching the results of parameter-less operations using the @cached simple annotation. In the following example, the Fibonacci number of a given Integer is calculated using the fibonacci recursive operation displayed in the listing below. Since the fibonacci operation is declared as cached, it is only executed once for each distinct Integer and subsequent calls on the same target return the cached result. Therefore, when invoked in line 1, the body of the operation is called 16 times. By contrast, if no @cached annotation was specified, the body of the operation would be called recursively 1973 times. This feature is particularly useful for performing queries on large models and caching their results without needing to introduce explicit variables that store the cached results.

It is worth noting that caching works by reference, which means that all clients of a cached method for a given context will receive the same returned object. As such, if the first client modifies the returned object in some way (e.g. sets a property in the case of an object or adds an element in the case of the collection), subsequent clients of the method for the same context will receive the modified object/collection.

15.fibonacci().println();

@cached
operation Integer fibonacci() : Integer {
  if (self = 1 or self = 0) {
    return 1;
  }
  else {
    return (self-1).fibonacci() + (self-2).fibonacci();
  }
}

Types

As is the case for most programming languages, EOL defines a built-in system of types, illustrated in the figure below. The Any type, inspired by the OclAny type of OCL, is the basis of all types in EOL including Collection types.

classDiagram
class ModelElementType {
  -model: String
  -type: String
}
class Native {
  -implementation: String
}
ModelElementType --|> Any
Any <|-- Native
Any <|-- Collection
Any <|-- Map
Collection <|-- Bag
Collection <|-- Set
Collection <|-- OrderedSet
Collection <|-- Sequence
PrimitiveType --|> Any
PrimitiveType <|-- Integer
PrimitiveType <|-- String
PrimitiveType <|-- Boolean
PrimitiveType <|-- Real

The operations supported by instances of the Any type are outlined in the table below[^2].

SignatureDescription
asBag() : BagReturns a new Bag containing the object
asBoolean() : BooleanReturns a Boolean based on the string representation of the object. If the string representation is not of an acceptable format, an error is raised
asInteger() : IntegerReturns an Integer based on the string representation of the object. If the string representation is not of an acceptable format, an error is raised
asOrderedSet() : OrderedSetReturns a new OrderedSet containing the object
asReal() : RealReturns a Real based on the string representation of the object. If the string representation is not of an acceptable format, an error is raised
asDouble() : DoubleReturns a Java Double based on the string representation of the object. If the string representation is not of an acceptable format, an error is raised
asFloat() : FloatReturns a Java Float based on the string representation of the object. If the string representation is not of an acceptable format, an error is raised
asSequence() : SequenceReturns a new Sequence containing the object
asSet() : SetReturns a new Set containing the object
asString() : StringReturns a string representation of the object
err([prefix : String]) : AnyPrints a string representation of the object on which it is invoked to the error stream prefixed with the optional prefix string and returns the object on which it was invoked. In this way, the err operation can be used for debugging purposes in a non-invasive manner
errln([prefix : String]) : AnyHas the same effects as the err operation but also produces a new line in the output stream.
format([pattern : String]) : StringUses the provided pattern to form a String representation of the object on which the method is invoked. The pattern argument must conform to the format string syntax defined by Java^3.
hasProperty(name : String) : BooleanReturns true if the object has a property with the specified name or false otherwise
ifUndefined(alt : Any) : AnyIf the object is undefined, it returns alt else it returns the object
isDefined() : BooleanReturns true if the object is defined and false otherwise
isKindOf(type : Type) : BooleanReturns true if the object is of the given type or one of its subtypes and false otherwise
isTypeOf(type : Type) : BooleanReturns true if the object is of the given type and false otherwise
isUndefined() : BooleanReturns true if the object is undefined and false otherwise
owningModel() : ModelReturns the model that contains this object or an undefined value otherwise
print([prefix : String]) : AnyPrints a string representation of the object on which it is invoked to the regular output stream, prefixed with the optional prefix string and returns the object on which it was invoked. In this way, the print operation can be used for debugging purposes in a non-invasive manner
println([prefix : String]) : AnyHas the same effects as the print operation but also produces a new line in the output stream.
type() : TypeReturns the type of the object.

Primitive Types

EOL provides four primitive types: String, Integer, Real and Boolean. The String type represents a finite sequence of characters and supports the following operations which can be invoked on its instances.

SignatureDescription
characterAt(index : Integer) : StringReturns the character in the specified index
concat(str : String) : StringReturns a concatenated form of the string with the str parameter
endsWith(str : String) : BooleanReturns true iff the string ends with str
firstToLowerCase() : StringReturns a new string the first character of which has been converted to lower case
firstToUpperCase() : StringReturns a new string, the first character of which has been converted to upper case
isInteger() : BooleanReturns true iff the string is an integer
isReal() : BooleanReturns true iff the string is a real number
isSubstringOf(str : String) : BooleanReturns true iff the string the operation is invoked on is a substring of str
length() : IntegerReturns the number of characters in the string
matches(reg : String) : BooleanReturns true if there are occurrences of the regular expression reg in the string
pad(length : Integer, padding : String, right : Boolean) : StringPads the string up to the specified length with specified padding (e.g. "foo".pad(5, "*", true) returns "foo**")
replace(source : String, target : String) : StringReturns a new string in which all instances of source have been replaced with instances of target
split(reg : String) : Sequence(String)Splits the string using as a delimiter the provided regular expression, reg, and returns a sequence containing the parts
startsWith(str : String) : BooleanReturns true iff the string starts with str
substring(index : Integer) : StringReturns a sub-string of the string starting from the specified index and extending to the end of the original string
substring(startIndex : Integer, endIndex : Integer) : StringReturns a sub-string of the string starting from the specified startIndex and ending at endIndex
toCharSequence() : Sequence(String)Returns a sequence containing all the characters of the string
toLowerCase() : StringReturns a new string where all the characters have been converted to lower case
toUpperCase() : StringReturns a new string where all the characters have been converted to upper case
trim() : StringReturns a trimmed copy of the string

The Real type represents real numbers and provides the following operations.

SignatureDescription
abs() : RealReturns the absolute value of the real
ceiling() : IntegerReturns the nearest Integer that is greater than the real
floor() : IntegerReturns the nearest Integer that is less than the real
log() : RealReturns the natural logarithm of the real
log10() : RealReturns the 10-based logarithm of the real
max(other : Real) : RealReturns the maximum of the two reals
min(other : Real) : RealReturns the minimum of the two reals
pow(exponent : Real) : RealReturns the real to the power of exponent
round() : IntegerRounds the real to the nearest Integer

The Integer type represents natural numbers and negatives and extends the Real primitive type. It also defines the following operations:

SignatureDescription
iota(end : Integer, step : Integer) : Sequence(Integer)Returns a sequence of integers up to end using the specified step (e.g. 1.iota(10,2) returns Sequence{1,3,5,7,9})
mod(divisor : Integer) : IntegerReturns the remainder of dividing the integer by the divisor
to(other : Integer) : Sequence(Integer)Returns a sequence of integers (e.g. 1.to(5) returns Sequence{1,2,3,4,5})
toBinary() : StringReturns the binary representation of the integer (e.g. 6.toBinary() returns “110”)
toHex() : StringReturns the hexadecimal representation of the integer (e.g. 42.toBinary() returns “2a”)

Finally, the Boolean type represents true/false states and provides no additional operations to those provided by the base Any type.

Collections and Maps

EOL provides four types of collections and a Map type. The Bag type represents non-unique, unordered collections and implements the java.util.Collection interface, the Sequence type represents non-unique, ordered collections and implements the java.util.List interface, the Set type represents unique and unordered collections and implements the java.util.Set interface, the OrderedSet represents unique and ordered collections. Since version 2.0, there are also two concurrent collection types, which can safely be modified from multiple threads. These are ConcurrentBag and ConcurrentSet, which are thread-safe variants of the Bag and Set types respectively.

All collection types inherit from the abstract Collection type. Apart from simple operations, EOL also supports logic operations on collections. The following operations (along with any operations declared on the java.util.Collection interface) apply to all types of collections:

SignatureDescription
add(item : Any) : BooleanAdds an item to the collection. If the collection is a set, addition of duplicate items has no effect. Returns true if the collection increased in size: this is always the case for bags and sequences, and for sets and ordered sets it is true if the element was not part of the collection before.
addAll(col : Collection) : BooleanAdds all the items of the col argument to the collection. If the collection is a set, it only adds items that do not already exist in the collection. Returns true if this collection changed as a result of the call
asBag()Returns a Bag that contains the same elements as the collection.
asOrderedSet()Returns a duplicate-free OrderedSet that contains the same elements as the collection.
asSequence()Returns a Sequence that contains the same elements as the collection.
asSet()Returns a duplicate-free Set that contains the same elements as the collection.
clear()Empties the collection
clone() : CollectionReturns a new collection of the same type containing the same items with the original collection
concat() : StringReturns the string created by converting each element of the collection to a string
concat(separator : String) : StringReturns the string created by converting each element of the collection to a string, using the given argument as a separator
count(item : Any) : IntegerReturns the number of times the item exists in the collection
excludes(item : Any) : BooleanReturns true if the collection excludes the item
excludesAll(col : Collection) : BooleanReturns true if the collection excludes all the items of collection col
excluding(item : Any) : CollectionReturns a new collection that excludes the item -- unlike the remove() operation that removes the item from the collection itself
excludingAll(col : Collection) : CollectionReturns a new collection that excludes all the elements of the col collection
flatten() : CollectionRecursively flattens all items that are of collection type and returns a new collection where no item is a collection itself
includes(item : Any) : BooleanReturns true if the collection includes the item
includesAll(col : Collection) : BooleanReturns true if the collection includes all the items of collection col
including(item : Any) : CollectionReturns a new collection that also contains the item -- unlike the add() operation that adds the item to the collection itself
includingAll(col : Collection) : CollectionReturns a new collection that is a union of the two collections. The type of the returned collection (i.e. Bag, Sequence, Set, OrderedSet) is same as the type of the collection on which the operation is invoked
isEmpty() : BooleanReturns true if the collection does not contain any elements and false otherwise
min() : RealReturns the minimum of all reals/integers in the collection, or 0 if it is empty
min(default : Real) : RealReturns the minimum of all reals/integers in the collection, or the default value if it is empty
max() : RealReturns the maximum of all reals/integers in the collection, or 0 if it is empty
max(default : Real) : RealReturns the maximum of all reals/integers in the collection, or the default value if it is empty
notEmpty() : BooleanReturns true if the collection contains any elements and false otherwise
powerset() : SetReturns the set of all subsets of the collection
product() : RealReturns the product of all reals/integers in the collection
random() : AnyReturns a random item from the collection
remove(item : Any) : BooleanRemoves an item from the collection. Returns true if the collection contained the specified element
removeAll(col : Collection) : BooleanRemoves all the items of col from the collection. Returns true if the collection changed as a result of the call
size() : IntegerReturns the number of items the collection contains
sum() : RealReturns the sum of all reals/integers in the collection

The following operations apply to ordered collection types (i.e. Sequence and OrderedSet):

SignatureDescription
at(index : Integer) : AnyReturns the item of the collection at the specified index
first() : AnyReturns the first item of the collection
fourth() : AnyReturns the fourth item of the collection
indexOf(item : Any) : IntegerReturns the index of the item in the collection or -1 if it does not exist
invert() : CollectionReturns an inverted copy of the collection
last() : AnyReturns the last item of the collection
removeAt(index : Integer) : AnyRemoves and returns the item at the specified index.
second() : AnyReturns the second item of the collection
third() : AnyReturns the third item of the collection

Also, EOL collections support the following first-order operations. Apart from aggregate and closure, all of these operations have a parallel variant which can take advantage of multiple cores to improve performance. All computations contained in these operations are assumed to be free from side-effects (i.e. do not mutatate global variables).

Aside from the following built-in first-order operations which are evaluated eagerly, all Collection types in the Java implementation of EOL support Streams. This allows for chains of queries and transformations on collections to be evaluated more efficiently. A stream can be obtained by calling the stream() method on the collection. The API is defined by the Java standard library^4.

SignatureDescription
atLeastNMatch(iterator : Type | condition, n : Integer) : BooleanReturns true if there are n or more items in the collection that satisfy the condition
atMostNMatch(iterator : Type | condition, n : Integer) : BooleanReturns true if there are n or fewer items in the collection that satisfy the condition
aggregate(iterator : Type | keyExpression, valueExpression) : MapReturns a map containing key-value pairs produced by evaluating the key and value expressions on each item of the collection that is of the specified type
closure(iterator : Type | expression) : CollectionReturns a collection containing the results of evaluating the transitive closure of the results produced by the expression on each item of the collection that is of the specified type. For example, if t is a tree model element, `t.closure(it
collect(iterator : Type | expression) : CollectionReturns a collection containing the results of evaluating the expression on each item of the collection that is of the specified type
count(iterator : Type | condition) : IntegerReturns the number of elements in the collection that satisfy the condition
exists(iterator : Type | condition) : BooleanReturns true if there exists at least one item in the collection that satisfies the condition
forAll(iterator : Type | condition) : BooleanReturns true if all items in the collection satisfy the condition
nMatch(iterator : Type | condition, n : Integer) : BooleanReturns true if there are exactly n items in the collection that satisfy the condition
none(iterator : Type | condition) : BooleanReturns true if there are no items in the collection that satisfy the condition
one(iterator : Type | condition) : BooleanReturns true if there exists exactly one item in the collection that satisfies the condition
reject(iterator : Type | condition) : CollectionReturns a sub-collection containing only items of the specified type that do not satisfy the condition
rejectOne(iterator : Type | condition) : CollectionReturns a sub-collection containing all elements except the first element which does not satisfy the condition
select(iterator : Type | condition) : CollectionReturns a sub-collection containing only items of the specified type that satisfy the condition
selectByKind(Type) : CollectionReturns a sub-collection containing only items of the specified type and subtypes
selectByType(Type) : CollectionReturns a sub-collection containing only items of the specified type only
selectOne(iterator : Type | condition) : AnyReturns any element that satisfies the condition
sortBy(iterator: Type | expression) : CollectionReturns a copy of the collection sorted by the results of evaluating the expression on each item of the collection that conforms to the iterator type. The expression should return either an Integer, a String or an object that is an instance of Comparable. The ordering is calculated as follows: for integers, smaller to greater; for Strings, as defined by the compareTo method of Java strings; for Comparable objects, according to the semantics of the type's compareTo method implementation.

The Map type (which implements the java.util.Map interface) represents a Set of key-value pairs in which the keys are unique. Since version 2.0, there is also a thread-safe ConcurrentMap type, which implements the java.util.concurrent.ConcurrentMap interface. The following operations are supported:

SignatureDescription
clear()Clears the map
containsKey(key : Any) : BooleanReturns true if the map contains the specified key
containsValue(value : Any) : BooleanReturns true if this map maps one or more keys to the specified value.
get(key : Any) : AnyReturns the value for the specified key
isEmpty() : BooleanReturns true if the map contains no key-value mappings.
keySet() : SetReturns the keys of the map
put(key : Any, value : Any)Adds the key-value pair to the map. If the map already contains the same key, the value is overwritten
putAll(map : Map)Copies all of the mappings from the specified map to this map.
remove(key : Any) : AnyRemoves the mapping for the specified key from this map if present. Returns the previous value associated with key.
size() : IntegerReturns the number of key-value mappings in this map.
values() : BagReturns the values of the map

Native Types

As discussed earlier, while the purpose of EOL is to provide significant expressive power to enable users to manage models at a high level of abstraction, it is not intended to be a general-purpose programming language. Therefore, there may be cases where users need to implement some functionality that is either not efficiently supported by the EOL runtime (e.g. complex mathematical computations) or that EOL does not support at all (e.g. developing user interfaces, accessing databases). To overcome this problem, EOL enables users to create objects of the underlying programming environment by using native types. A native type specifies an implementation property that indicates the unique identifier for an underlying platform type. For instance, in a Java implementation of EOL the user can instantiate and use a Java class via its class identifier. Thus, the EOL excerpt in the listing below creates a Java window (Swing JFrame) and uses its methods to change its title and dimensions and make it visible.

var frame = new Native("javax.swing.JFrame");
frame.title = "Opened with EOL";
frame.setBounds(100,100,300,200);
frame.visible = true;

To pass arguments to the constructor of a native type, a parameter list must be added, such as that in the listing below.

var file = new Native("java.io.File")("myfile.txt");
file.absolutePath.println();

Static types can also be referenced in EOL and stored in a variable for convenience, as shown below.

var Collectors = Native("java.util.stream.Collectors");

Model Element Types

A model element type represents a meta-level classifier for model elements. Epsilon intentionally refrains from defining more details about the meaning of a model element type, to be able to support diverse modelling technologies where a type has different semantics. For instance an Ecore EClass, an XSD complex type and a Java class can all be regarded as model element types according to the implementation of the underlying modelling framework.

!!! info As EOL is decoupled from modelling technologies (e.g. EMF, Simulink), through Epsilon's Model Connectivity Layer, we refrain from referring to specific modelling technologies in this section as much as possible.

In case of multiple models, as well as the name of the type, the name of the model is also required to resolve a particular type since different models may contain elements of homonymous but different model element types. In case a model defines more than one type with the same name (e.g. in different packages), a fully qualified type name must be provided.

In terms of concrete syntax, inspired by ATL, the ! character is used to separate the name of the type from the name of the model it is defined in. For instance, Ma!A represents the type A of model Ma. Also, to support modelling technologies that provide hierarchical grouping of types (e.g. using packages) the :: notation is used to separate between packages and classes. A model element type supports the following operations:

SignatureDescription
all() : SetAlias for allOfKind() (for syntax-compactness purposes)
allInstances() : SetAlias for allOfKind() (for compatibility with OCL)
allOfKind() : SetReturns all the elements in the model that are instances either of the type itself or of one of its subtypes
allOfType() : SetReturns all the elements in the model that are instances of the type
createInstance() : AnyCreates an instance of the type in the model. The same can be achieved using the new operator (see below)
isInstantiable() : BooleanReturns true if the type is instantiable (i.e. non-abstract)

As an example of the concrete syntax, the listing below retrieves all the instances of the Class type (including instances of its subtypes) defined in the Core package of the UML 1.4 metamodel that are contained in the model named UML14.

UML14!Core::Foundation::Class.allInstances();

Creating and Deleting Model Elements

EOL provides the new and delete operators for creating and deleting model elements as shown below. The new operator is an alias for the createInstance() method above, and can also be used to create instances of primitive and native types (i.e Java classes).

var t : new Tree; // Creates a new instance of type Tree
var p : new Source!Person; // Creates a new Person in model Source
delete t; // Deletes the element created in line 1

Expressions

Literal Values

EOL provides special syntax constructs to create instances of each of the built-in types:

  • Integer literals are defined by using one or more decimal digits (such as 42 or 999). Optionally, long integers (with the same precision as a Java Long) can be produced by adding a “l” suffix, such as 42l.

  • Real literals are defined by:

    • Adding a decimal separator and non-empty fractional part to the integer part, such as 42.0 or 3.14. Please note that .2 and 2. are not valid literals.
    • Adding a floating point suffix: “f” and “F” denote single precision, and “d” and “D” denote double precision. For example, 2f or 3D.
    • Adding an exponent, such as 2e+1 (equal to 2e1) or 2e-1.
    • Using any combination of the above options.
  • String literals are sequences of characters delimited by single ('hi') or double ("hi") quotes. Quotes inside the string can be escaped by using a backslash, such as in 'A\'s' or "A\"s". Literal backslashes need to be escaped as well, such as in 'A\\B'. Special escape sequences are also provided: \n for a newline, \t for a horizontal tab and \r for a carriage return, among others.

  • Boolean literals use the true reserved keyword for the true Boolean value, and false reserved keyword for the false Boolean value.

  • Sequence and most other collections (except Maps) also have literals. Their format is T {e}, where T is the name of the type and e are zero or more elements, separated by commas. For instance, Sequence{} is the empty sequence, and Set {1, 2, 3} is the set of numbers between 1 and 3.

  • Map literals are similar to the sequential collection literals, but their elements are of the form key = value. For instance, Map{'a' = 1, 'b' = 2} is a map which has two keys, “a” and “b”, which map to the integer values 1 and 2, respectively.

    Please note that, when defining an element such as 1 = 2 = 3, the key would be 1 and the value would be the result of evaluating 2 = 3 (false). If you would like to use the result of the expression 1 = 2 as key, you will need to enclose it in parenthesis, such as in (1 = 2) = 3.

Feature Navigation

Since EOL needs to manage models defined using object oriented modelling technologies, it provides expressions to navigate properties and invoke simple and declarative operations on objects.

In terms of concrete syntax, . is used as a uniform operator to access a property of an object and to invoke an operation on it. The -> operator, which is used in OCL to invoke first-order logic operations on sets, has been also preserved for syntax compatibility reasons. In EOL, every operation can be invoked both using the . or the -> operators, with a slightly different semantics to enable overriding the built-in operations. If the . operator is used, precedence is given to the user-defined operations, otherwise precedence is given to the built-in operations. For instance, the Any type defines a println() method that prints the string representation of an object to the standard output stream. In the listing below, the user has defined another parameterless println() operation in the context of Any. Therefore the call to println() in line 1 will be dispatched to the user-defined println() operation defined in line 3. In its body the operation uses the -> operator to invoke the built-in println() operation (line 4).

"Something".println();

operation Any println() : Any {
  ("Printing : " + self)->println();
}

Escaping Reserved Keywords

Due to the variable nature of (meta-)models and the various domain-specific languages of Epsilon (including EOL itself), feature navigation calls may clash with reserved keywords, leading to a parsing error. Backticks can be used to escape such keywords. For example, if a model element contains a feature called operation, then this can be navigated as shown in the listing below.

var op = modelElement.`operation`;

Arithmetical and Comparison Operators

EOL provides common operators for performing arithmetical computations and comparisons illustrated in the following two tables respectively.

OperatorDescription
+Adds reals/integers and concatenates strings
-Subtracts reals/integers
- (unary).Returns the negative of a real/integer
*Multiplies reals/integers
/Divides reals/integers
+=Adds the r-value to the l-value
-=Subtracts the r-value from the l-value
*=Multiplies the l-value by the r-value
/=Divides the l-value by the r-value
++Increments the integer by one
--Decrements the integer by one
OperatorDescription
=Returns true if the left hand side equals the right hand side. In the case of primitive types (String, Boolean, Integer, Real) the operator compares the values; in the case of objects it returns true if the two expressions evaluate to the same object
==Same as =
<>Is the logical negation of the (=) operator
!=Same as <>
>For reals/integers returns true if the left hand side is greater than the right hand side number
<For reals/integers returns true if the left hand side is less than the right hand side number
>=For reals/integers returns true if the left hand side is greater or equal to the right hand side number
<=For reals/integers returns true if the left hand side is less or equal to then right hand side number

Logical Operators

EOL provides common operators for performing logical computations illustrated in the table below. Logical operations apply only to instances of the Boolean primitive type.

!!! warning “Operator Precedence” All logical operators in EOL have the same priority. This is in contrast to other languages like Java where e.g. and has a higher priority than or. As a result, while true || true && false returns true in Java, the equivalent true or true and false expression in EOL returns false. Default priorities can be overridden using brackets (true or (true and false) in this case.)

OperatorDescription
andReturns the logical conjunction of the two expressions
orReturns the logical disjunction of the two expressions
notReturns the logical negation of the expression
impliesReturns the logical implication of the two expressions (see below)
xorReturns true if only one of the involved expressions evaluates to true and false otherwise

The truth table for the implies logical operator is below.

LeftRightResult
truetruetrue
truefalsefalse
falsetruetrue
falsefalsetrue

Ternary Operator

As of version 2.0, EOL has a ternary operator which is a concise way of using if/else as an expression. The semantics and syntax are similar to Java, but can be used anywhere as an expression, not only in variable assignments or return statements. The listing below shows some examples of this[^5]. Note that is also possible to use the else keyword in place of the colon for separating the true and false expressions for greater clarity. As one would expect, the branches are evaluated lazily: only one of the branches is executed and returned as the result of the expression depending on the value of the Boolean expression before the question mark.

var result = 2+2==4 ? "Yes" else "No";
return ((result == "Yes" ? 1 : 0) * 2 == 2).mod(2) == 0;

Safe Navigation and Elvis Operator

As of version 2.1, EOL supports safe null navigation ?., which makes it more concise to chain feature call expressions without resorting to defensive null / isDefined() checks. In the following example, the variable result will be null, and the program won't crash since the safe navigation operator is used.

var a = null;
var result = a?.someProperty?.anotherProperty;

The null variant of the “Elvis operator” can also be used to simplify null check ternary expressions, as shown in the example below.

var a = null;
var b = "result";
var c = a != null ? a : b;
var d = a ?: b;
assert(c == d);

As with the ternary operator, the Elvis operator can also be used anywhere an expression is expected, not just in assignments.

Enumerations

EOL provides the # operator for accessing enumeration literals. For example, the VisibilityEnum#vk_public expression returns the value of the literal vk_public of the VisibilityEnum enumeration. For EMF metamodels, VisibilityEnum#vk_public.instance can also be used.

Statements

Variable Declaration Statement

A variable declaration statement declares the name and (optionally) the type and initial value of a variable in an EOL program. If no type is explicitly declared, the variable is assumed to be of type Any. For variables of primitive type, declaration automatically creates an instance of the type with the default values presented in the table below. For non-primitive types the user has to explicitly assign the value of the variable either by using the new keyword or by providing an initial value expression. If neither is done the value of the variable is undefined. Variables in EOL are strongly-typed. Therefore a variable can only be assigned values that conform to its type (or a sub-type of it).

TypeDefault value
Integer0
Booleanfalse
String""
Real0.0
Scope

The scope of variables in EOL is generally limited to the block of statements where they are defined, including any nested blocks. Nevertheless, as discussed in the sequel, there are cases in task-specific languages that build atop EOL where the scope of variables is expanded to other non-nested blocks as well. EOL also allows variable shadowing; that is to define a variable with the same name in a nested block that overrides a variable defined in an outer block.

The listing below provides an example of declaring and using variables.

  • Line 1 defines a variable named i of type Integer and assigns it an initial value of 5.
  • Line 2 defines a variable named c of type Class (from model Uml) and creates a new instance of the type in the model (by using the new keyword).
  • The commented out assignment statement of line 3 would raise a runtime error since it would attempt to assign a String value to an Integer variable.
  • The condition of line 4 returns true since the c variable has been initialized before.
  • Line 5 defines a new variable also named i that is of type String and which overrides the Integer variable declared in line 1.
  • Therefore the assignment statement of line 6 is legitimate as it assigns a string value to a variable of type String.
  • Finally, as the program has exited the scope of the if statement, the assignment statement of line 7 is also legitimate as it refers to the i variable defined in line 1.
var i : Integer = 5;
var c : new Uml!Class;
//i = "somevalue";
if (c.isDefined()) {
  var i : String;
  i = "somevalue";
}
i = 3;

Assignment Statement

The assignment statement is used to update the values of variables and properties of native objects and model elements.

Variable Assignment

When the left hand side of an assignment statement is a variable, the value of the variable is updated to the object to which the right hand side evaluates to. If the type of the right hand side is not compatible (kind-of relationship) with the type of the variable, the assignment is illegal and a runtime error is raised. Assignment to objects of primitive types is performed by value while assignment to instances of non-primitive values is performed by reference. For example, in the listing below, in line 1 the value of the a variable is set to a new Class in the Uml model. In line 2, a new untyped variable b is declared and its value is assigned to a. In line 3 the name of the class is updated to Customer and thus, line 4 prints Customer to the standard output stream.

var a : new Uml!Class;
var b = a;
a.name = "Customer";
b.name.println();

On the other hand, in the listing below, in line 1 the a String variable is declared. In line 2 an untyped variable b is declared. In line 3, the value of a is changed to Customer (which is an instance of the primitive String type). This has no effect on b and thus line 4 prints an empty string to the standard output stream.

var a : String;
var b = a;
a = "Customer";
b.println();
Native Object Property Assignment

When the left hand side of the assignment is a property of a native object, deciding on the legality and providing the semantics of the assignment is delegated to the execution engine. For example, in a Java-based execution engine, given that x is a native object, the statement x.y = a may be interpreted as x.setY(a) or if x is an instance of a map x.put("y",a). By contrast, in a C# implementation, it can be interpreted as x.y = a since the language natively supports properties in classes.

Model Element Property Assignment

When the left hand side of the assignment is a property of a model element, the model that owns the particular model element (accessible using the ModelRepository.getOwningModel() operation) is responsible for implementing the semantics of the assignment using its associated propertyGetter. For example, if x is a model element, the statement x.y = a may be interpreted using the Java code of the first listing below if x belongs to an EMF-based model or using the Java code of the second listing if it belongs to an MDR-based model.

EStructuralFeature feature = x.eClass().getEStructuralFeature("y");
x.eSet(feature, a);
StructuralFeature feature = findStructuralFeature(x.refClass(), "y");
x.refSetValue(feature, a);

Special Assignment Statement

In task-specific languages, an assignment operator with task-specific semantics is often required. Therefore, EOL provides an additional assignment operator. In standalone EOL, the operator has the same semantics with the primary assignment operator discussed above, however task-specific languages can redefine its semantics to implement custom assignment behaviour. For example, consider the simple model-to-model transformation of the listing below where a simple object oriented model is transformed to a simple database model using an ETL transformation.

rule Class2Table
  transform c : OO!Class
  to t : DB!Table {

    t.name = c.name;
}

rule Attribute2Column
  transform a : OO!Attribute
  to c : DB!Column {
    
    c.name = a.name;
    //c.owningTable = a.owningClass;
    c.owningTable ::= a.owningClass;
}

The Class2Table rule transforms a Class of the OO model into a Table in the DB model and sets the name of the table to be the same as the name of the class. Rule Atribute2Column transforms an Attribute from the OO model into a Column in the DB model. Except for setting its name (line 12), it also needs to define that the column belongs to the table which corresponds to the class that defines the source attribute. The commented-out assignment statement of line 13 cannot be used for this purpose since it would illegaly attempt to assign the owningTable feature of the column to a model element of an inappropriate type (OO!Class). However, the special assignment operator in ETL has language-specific semantics, and thus in line 14 it assigns to the owningTable feature not the class that owns the attribute but its corresponding table (calculated using the Class2Table rule) in the DB model.

If Statement

As in most programming languages, an if statement consists of a condition, a block of statements that is executed if the condition is satisfied and (optionally) a block of statements that is executed otherwise. As an example, in the listing below, if variable a holds a value that is greater than 0 the statement of line 3 is executed, otherwise the statement of line 5 is executed.

if (a > 0) {
  "A is greater than 0".println();
}
else { "A is less equal than 0".println(); }

Switch Statement

A switch statement consists of an expression and a set of cases, and can be used to implement multi-branching. Unlike Java/C, switch in EOL doesn't by default fall through to the next case after a successful one. Therefore, it is not necessary to add a break statement after each case. To enable falling through to all subsequent cases you can use the continue statement. Also, unlike Java/C, the switch expression can return anything (not only integers). As an example, when executed, the code in the listing below prints 2 while the code in the following listing prints 2,3,default.

var i = "2";

switch (i) {
  case "1" : "1".println(); 
  case "2" : "2".println();
  case "3" : "3".println();
  default : "default".println(); 
}
var i = "2";

switch (i) {
  case "1" : "1".println(); 
  case "2" : "2".println(); continue;
  case "3" : "3".println();
  default : "default".println(); 
}

While Statement

A while statement consists of a condition and a block of statements which are executed as long as the condition is satisfied. For example, in the listing below, the body of the while statement is executed 5 times printing the numbers 0 to 4 to the output console. Inside the body of a while statement, the built-in read-only loopCount integer variable holds the number of times the innermost loop has been executed so far (including the current iteration). Right after entering the loop for the first time and before running the first statement in its body, loopCount is set to 1, and it is incremented after each following iteration.

var i : Integer = 0;
while (i < 5) {
  // both lines print the same thing
  i.println();
  (loopCount - 1).println();
  // increment the counter
  i = i+1;
}

For Statement

In EOL, for statements are used to iterate the contents of collections. A for statement defines a typed iterator and an iterated collection as well as a block of statements that is executed for every item in the collection that has a kind-of relationship with the type defined by the iterator. As with the majority of programming languages, modifying a collection while iterating it raises a runtime error. To avoid this situation, users can use the clone() built-in operation of the Collection type.

var col : Sequence = Sequence{"a", 1, 2, 2.5, "b"};
for (r : Real in col) {
  r.print();
  if (hasMore){",".print();}
}

Inside the body of a for statement, two built-in read-only variables are visible: the loopCount integer variable and the hasMore boolean variable. hasMore is used to determine if there are more items if the collection for which the loop will be executed. For example, in the listing below the col heterogeneous Sequence is defined that contains two strings (a and b), two integers (1,2) and one real (2.5). The for loop of line 2 only iterates through the items of the collection that are of kind Real and therefore prints 1,2,2.5 to the standard output stream.

Break, BreakAll and Continue Statements

To exit from for and while loops on demand, EOL provides the break and breakAll statements. The break statement exits the innermost loop while the breakAll statement exits all outer loops as well. On the other hand, to skip a particular loop and proceed with the next one, EOL provides the continue statement. For example, the program in the listing below, prints 2,1 3,1 to the standard output stream.

for (i in Sequence{1..3}) {
  if (i = 1) {continue;}
  for (j in Sequence{1..4}) {
    if (j = 2) {break;}
    if (j = 3) {breakAll;}
    (i + "," + j).println();
  }
}

Throw Statement

EOL provides the throw statement for throwing a value as an Java exception. This is especially useful when invoking EOL scripts from Java code: by catching and processing the exception, the Java code may be able to automatically handle the problem without requiring user input. Any value can be thrown, as shown in the listing below where we throw a number and a string.

throw 42;
throw "Error!";

Transaction Statement

The underlying EMC layer provides support for transactions in models. To utilize this feature EOL provides the transaction statement. A transaction statement (optionally) defines the models that participate in the transaction. If no models are defined, it is assumed that all the models that are accessible from the enclosing program participate. When the statement is executed, a transaction is started on each participating model. If no errors are raised during the execution of the contained statements, any changes made to model elements are committed. On the other hand, if an error is raised the transaction is rolled back and any changes made to the models in the context of the transaction are undone. The user can also use the abort statement to explicitly exit a transaction and roll-back any changes done in its context. In the listing below, an example of using this feature in a simulation problem is illustrated.

var system : System.allInstances.first();

for (i in Sequence {1..100}) {

  transaction {
    
    var failedProcessors : Set; 

    while (failedProcessors.size() < 10) {
        failedProcessors.add(system.processors.random());
    }

    for (processor in failedProcessors) {
        processor.failed = true;
        processor.moveTasksElsewhere();
    }

    system.evaluateAvailability();

    abort;
  }

}

In this problem, a system consists of a number of processors. A processor manages some tasks and can fail at any time. The EOL program in the listing above performs 100 simulation steps, in every one of which 10 random processors from the model (lines 7-11) are marked as failed by setting their failed property to true (line 14). Then, the tasks that the failed processors manage are moved to other processors (line 15). Finally the availability of the system in this state is evaluated.

After a simulation step, the state of the model has been drastically changed since processors have failed and tasks have been relocated. To be able to restore the model to its original state after every simulation step, each step is executed in the context of a transaction which is explicitly aborted (line 20) after evaluating the availability of the system. Therefore after each simulation step the model is restored to its original state for the next step to be executed.

Extended Properties

Quite often, during a model management operation it is necessary to associate model elements with information that is not supported by the metamodel they conform to. For instance, the EOL program in the listing below calculates the depth of each Tree element in a model that conforms to the Tree metamodel displayed below.

classDiagram
class Tree {
  +label: String
  +parent: Tree
  +children: Tree[*]
}
Tree -- Tree  

As the Tree metamodel doesn't support a depth property in the Tree metaclass, each Tree has to be associated with its calculated depth using the depths map defined in line 1. Another approach would be to extend the Tree metamodel to support the desired depth property; however, applying this technique every time an additional property is needed for some model management operation would quickly pollute the metamodel with properties of secondary importance.

var depths = new Map;

for (n in Tree.allInstances.select(t|not t.parent.isDefined())) {
  n.setDepth(0);
}

for (n in Tree.allInstances) {
  (n.name + " " + depths.get(n)).println();
}

operation Tree setDepth(depth : Integer) {
  depths.put(self,depth);
  for (c in self.children) {
    c.setDepth(depth + 1);
  }
}

To simplify the code required in such cases, EOL provides the concept of extended properties. In terms of concrete syntax, an extended property is a normal property, the name of which starts with the tilde character (~). With regards to its execution semantics, the first time the value of an extended property of an object is assigned, the property is created and associated with the object. Then, the property can be accessed as a normal property. If an extended property is accessed before it is assigned, it returns null. The listing below demonstrates using a ~depth extended property to eliminate the need for using the depths map in the listing that follows it.

for (n in Tree.allInstances.select(t|not t.parent.isDefined())) {
  n.setDepth(0);
}

for (n in Tree.allInstances) {
  (n.name + " " + n.~depth).println();
}

operation Tree setDepth(depth : Integer) {
  self.~depth = depth;
  for (c in self.children) {
    c.setDepth(depth + 1);
  }
}

Context-Independent User Input

A common assumption in model management languages is that model management tasks are only executed in a batch-manner without human intervention. However, as demonstrated in the sequel, it is often useful for the user to provide feedback that can precisely drive the execution of a model management operation.

Model management operations can be executed in a number of runtime environments in each of which a different user-input method is more appropriate. For instance when executed in the context of an IDE (such as Eclipse) visual dialogs are preferable, while when executed in the context of a server or from within an ANT workflow, a command-line user input interface is deemed more suitable. To abstract away from the different runtime environments and enable the user to specify user interaction statements uniformly and regardless of the runtime context, EOL provides the IUserInput interface that can be realized in different ways according to the execution environment and attached to the runtime context via the IEolContext.setUserInput(IUserInput userInput) method. The IUserInput specifies the methods presented in the table below.

SignatureDescription
inform(message : String)Displays the specified message to the user
confirm(message : String, [default : Boolean]) : BooleanPrompts the user to confirm if the condition described by the message holds
prompt(message : String, [default : String]) : StringPrompts the user for a string in response to the message
promptInteger(message : String, [default : Integer]) : IntegerPrompts the user for an Integer
promptReal(message : String, [default : Real]) : RealPrompts the user for a Real
choose(message : String, options : Sequence, [default : Any]) : AnyPrompts the user to select one of the options
chooseMany(message : String, options : Sequence, [default : Sequence]) : SequencePrompts the user to select one or more of the options

As displayed above, all the methods of the IUserInput interface accept a default parameter. The purpose of this parameter is dual. First, it enables the designer of the model management program to prompt the user with the most likely value as a default choice and secondly it enables a concrete implementation of the interface (UnattendedExecutionUserInput) which returns the default values without prompting the user at all and thus, can be used for unattended execution of interactive Epsilon programs. The figures below demonstrate the interfaces through which input is required by the user when the exemplar System.user.promptInteger('Please enter a number', 1); statement is executed using an Eclipse-based and a command-line-based IUserInput implementation respectively.

Example of an Eclipse-based IUserInputimplementation

Example of a command-line-based IUserInputimplementation

User-input facilities have been found to be particularly useful in all model management tasks. Such facilities are essential for performing operations on live models such as model validation and model refactoring but can also be useful in model comparison where marginal matching decisions can be delegated to the user and model transformation where the user can interactively specify the elements that will be transformed into corresponding elements in the target model.

[^1]: Although the EOL parser permits loose statements (e.g. not contained in operations) between/after operations, these are ignored at runtime.

[^2]: Parameters within square brackets are optional

[^5]: For further examples of ternary operator, see https://git.eclipse.org/c/epsilon/org.eclipse.epsilon.git/tree/tests/org.eclipse.epsilon.eol.engine.test.acceptance/src/org/eclipse/epsilon/eol/engine/test/acceptance/TernaryTests.eol