The Epsilon Object Language (EOL)¶

EOL is the core expression language of Epsilon, and the foundation for task-specific languages for tasks such as model-validation, model-to-text transformation, model-to-model transformation and model migration. 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.

Try EOL online

You can run and fiddle with an EOL program that queries a project scheduling model in the online Epsilon Playground.

Syntax¶

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. 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 example, consider the code excerpts 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.

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

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

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

On the other hand, in the following 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.

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();
}

Statements after operations are ignored

Any loose statements after the first operation of an EOL program will be ignored by the EOL interpreter e.g.

"This statement will be executed".println();

operation foo() {}

"This statement won't be executed".println();

Statements outside operations in imported modules are ignored

Any statements outside operations in imported EOL modules will be ignored.

For example, suppose you had this utilities.eol file:

"This statement will be ignored".println();

operation useful() { /* code */ }

If you tried to run this main.eol file, the above println() call would not be executed:

import "utilities.eol";

useful();

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

Signature	Description
asBag() : Bag	Returns a new Bag containing the object
asBoolean() : Boolean	Returns 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() : Integer	Returns 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() : OrderedSet	Returns a new OrderedSet containing the object
asReal() : Real	Returns 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() : Double	Returns 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() : Float	Returns 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() : Sequence	Returns a new Sequence containing the object
asSet() : Set	Returns a new Set containing the object
asString() : String	Returns a string representation of the object
asVar(name : String) : Any	Creates a new variable with the specified name out of the object, and returns the object
err([prefix : String]) : Any	Prints 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]) : Any	Has the same effects as the `err` operation but also produces a new line in the output stream.
format([pattern : String]) : String	Uses 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².
hasProperty(name : String) : Boolean	Returns true if the object has a property with the specified name or false otherwise
ifUndefined(alt : Any) : Any	If the object is undefined, it returns alt else it returns the object
isDefined() : Boolean	Returns true if the object is defined and false otherwise
isKindOf(type : Type) : Boolean	Returns true if the object is of the given type or one of its subtypes and false otherwise
instanceOf(type : Type) : Boolean	Alias for `isKindOf`
isTypeOf(type : Type) : Boolean	Returns true if the object is of the given type and false otherwise
isUndefined() : Boolean	Returns true if the object is undefined and false otherwise
owningModel() : Model	Returns the model that contains this object or an undefined value otherwise
print([prefix : String]) : Any	Prints 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]) : Any	Has the same effects as the `print` operation but also produces a new line in the output stream.
type() : Type	Returns 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.

Signature	Description
characterAt(index : Integer) : String	Returns the character in the specified index
concat(str : String) : String	Returns a concatenated form of the string with the `str` parameter
endsWith(str : String) : Boolean	Returns true iff the string ends with `str`
escapeXml() : String	Returns a new string with escaped XML-reserved characters
firstToLowerCase() : String	Returns a new string the first character of which has been converted to lower case
ftlc() : String	Alias for `firstToLowerCase()`
firstToUpperCase() : String	Returns a new string, the first character of which has been converted to upper case
ftuc : String	Alias for `firstToUpperCase()`
isInteger() : Boolean	Returns true iff the string is an integer
isReal() : Boolean	Returns true iff the string is a real number
isSubstringOf(str : String) : Boolean	Returns true iff the string the operation is invoked on is a substring of `str`
length() : Integer	Returns the number of characters in the string
matches(reg : String) : Boolean	Returns true if there are occurrences of the regular expression `reg` in the string
pad(length : Integer, padding : String, right : Boolean) : String	Pads the string up to the specified length with specified padding (e.g. `"foo".pad(5, "", true)` returns `"foo*"`)
replace(reg : String, replacement : String) : String	Returns a new string in which all matches of the regular expression `reg` have been replaced with instances of `replacement`
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) : Boolean	Returns true iff the string starts with `str`
substring(index : Integer) : String	Returns 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) : String	Returns 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() : String	Returns a new string where all the characters have been converted to lower case
toUpperCase() : String	Returns a new string where all the characters have been converted to upper case
trim() : String	Returns a trimmed copy of the string

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

Signature	Description
abs() : Real	Returns the absolute value of the real
ceiling() : Integer	Returns the nearest Integer that is greater than the real
floor() : Integer	Returns the nearest Integer that is less than the real
log() : Real	Returns the natural logarithm of the real
log10() : Real	Returns the 10-based logarithm of the real
max(other : Real) : Real	Returns the maximum of the two reals
min(other : Real) : Real	Returns the minimum of the two reals
pow(exponent : Real) : Real	Returns the real to the power of exponent
round() : Integer	Rounds 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:

Signature	Description
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) : Integer	Returns 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() : String	Returns the binary representation of the integer (e.g. 6.toBinary() returns "110")
toHex() : String	Returns 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 several 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:

Signature	Description
add(item : Any) : Boolean	Adds 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) : Boolean	Adds 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() : Collection	Returns a new collection of the same type containing the same items with the original collection
concat() : String	Returns the string created by converting each element of the collection to a string (equivalent to the `join` method used in some other languages)
concat(separator : String) : String	Returns the string created by converting each element of the collection to a string, using the given argument as a separator (equivalent to the `join` method used in some other languages)
count(item : Any) : Integer	Returns the number of times the item exists in the collection
excludes(item : Any) : Boolean	Returns true if the collection excludes the `item`
excludesAll(col : Collection) : Boolean	Returns true if the collection excludes all the items of collection col
excluding(item : Any) : Collection	Returns a new collection that excludes the item -- unlike the remove() operation that removes the `item` from the collection itself
excludingAll(col : Collection) : Collection	Returns a new collection that excludes all the elements of the col collection
flatten() : Collection	Recursively flattens all items that are of collection type and returns a new collection where no item is a collection itself
includes(item : Any) : Boolean	Returns true if the collection includes the `item`
includesAll(col : Collection) : Boolean	Returns true if the collection includes all the items of collection `col`
including(item : Any) : Collection	Returns a new collection that also contains the `item` -- unlike the add() operation that adds the `item` to the collection itself
includingAll(col : Collection) : Collection	Returns 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() : Boolean	Returns true if the collection does not contain any elements and false otherwise
min() : Real	Returns the minimum of all reals/integers in the collection, or 0 if it is empty
min(default : Real) : Real	Returns the minimum of all reals/integers in the collection, or the default value if it is empty
max() : Real	Returns the maximum of all reals/integers in the collection, or 0 if it is empty
max(default : Real) : Real	Returns the maximum of all reals/integers in the collection, or the default value if it is empty
notEmpty() : Boolean	Returns true if the collection contains any elements and false otherwise
powerset() : Set	Returns the set of all subsets of the collection
product() : Real	Returns the product of all reals/integers in the collection
random() : Any	Returns a random item from the collection
remove(item : Any) : Boolean	Removes an `item` from the collection. Returns true if the collection contained the specified element
removeAll(col : Collection) : Boolean	Removes all the items of `col` from the collection. Returns true if the collection changed as a result of the call
size() : Integer	Returns the number of items the collection contains
sum() : Real	Returns the sum of all reals/integers in the collection

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

Signature	Description
at(index : Integer) : Any	Returns the item of the collection at the specified index
first() : Any	Returns the first item of the collection
fourth() : Any	Returns the fourth item of the collection
indexOf(item : Any) : Integer	Returns the index of the item in the collection or -1 if it does not exist
invert() : Collection	Returns an inverted copy of the collection
last() : Any	Returns the last item of the collection
removeAt(index : Integer) : Any	Removes and returns the item at the specified index.
second() : Any	Returns the second item of the collection
third() : Any	Returns 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 mutate 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³.

Signature	Description
atLeastNMatch(iterator : Type \| condition, n : Integer) : Boolean	Returns true if there are `n` or more items in the collection that satisfy the condition
atMostNMatch(iterator : Type \| condition, n : Integer) : Boolean	Returns true if there are `n` or fewer items in the collection that satisfy the condition
aggregate(iterator : Type \| keyExpression, valueExpression) : Map	Returns 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) : Collection	Returns an ordered set 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\|it.children)` will return all its descendants
collect(iterator : Type \| expression) : Collection	Returns 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) : Integer	Returns the number of elements in the collection that satisfy the condition
exists(iterator : Type \| condition) : Boolean	Returns true if there exists at least one item in the collection that satisfies the condition
forAll(iterator : Type \| condition) : Boolean	Returns true if all items in the collection satisfy the condition
mapBy(iterator : Type \| expression) : Map	Returns a map containing the results of the expression as keys and the respective items of the collection as values.
nMatch(iterator : Type \| condition, n : Integer) : Boolean	Returns true if there are exactly `n` items in the collection that satisfy the condition
none(iterator : Type \| condition) : Boolean	Returns true if there are no items in the collection that satisfy the condition
one(iterator : Type \| condition) : Boolean	Returns true if there exists exactly one item in the collection that satisfies the condition
reject(iterator : Type \| condition) : Collection	Returns a sub-collection containing only items of the specified type that do not satisfy the condition
rejectOne(iterator : Type \| condition) : Collection	Returns a sub-collection containing all elements except the first element which does not satisfy the condition
select(iterator : Type \| condition) : Collection	Returns a sub-collection containing only items of the specified type that satisfy the condition
selectByKind(Type) : Collection	Returns a sub-collection containing only items of the specified type and subtypes
selectByType(Type) : Collection	Returns a sub-collection containing only items of the specified type only
selectOne(iterator : Type \| condition) : Any	Returns any element that satisfies the condition
sortBy(iterator: Type \| expression) : Collection	Returns 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:

Signature	Description
clear()	Clears the map
containsKey(key : Any) : Boolean	Returns true if the map contains the specified key
containsValue(value : Any) : Boolean	Returns true if this map maps one or more keys to the specified value.
get(key : Any) : Any	Returns the value for the specified key
isEmpty() : Boolean	Returns true if the map contains no key-value mappings.
keySet() : Set	Returns 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) : Any	Removes the mapping for the specified key from this map if present. Returns the previous value associated with key.
size() : Integer	Returns the number of key-value mappings in this map.
values() : Bag	Returns the values of the map

Tuples¶

Since version 2.2, EOL supports Tuples, which can be used to compose arbitrary data structures on-the-fly. A Tuple in EOL behaves like a Map<String, Object>, except that the values of the map can be accessed using literal property call expressions. There are three ways to instantiate a tuple, as shown below.

// After construction
var alice = new Tuple;
alice.name = "Alice";
alice.age = 32;

// During construction
var bob = new Tuple(name = "Bob", age = 28);

// Map Literal
var charlie = Tuple{"name" = "Charlie", "age" = 36};

If a non-existent property on a Tuple is accessed, an exception is thrown.

var p = new Tuple(name = "Alice", age = 32);

p.name.substring(0, 3); // "Ali"
p.age; // 32
p.occupation.isDefined(); // false
p.occupation.toUpperCase(); // Property 'occupation' not found

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:

Signature	Description
all() : Collection	Alias for getAllOfKind() (for syntax-compactness purposes)
allInstances() : Collection	Alias for getAllOfKind() (for compatibility with OCL)
getAllOfKind() : Collection	Returns all the elements in the model that are instances either of the type itself or of one of its subtypes
getAllOfType() : Collection	Returns all the elements in the model that are instances of the type
createInstance() : Any	Creates an instance of the type in the model. The same can be achieved using the `new` operator (see below)
isInstantiable() : Boolean	Returns 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.

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();
}

Navigating to the parent/children of model elements

EOL does not provide a technology-independent way of navigating to the parent/children of a model element. If you need to do this, you should use any methods provided by the underlying modelling platform. For example, as all elements of EMF models are instances of the EObject Java class, the me.eContainer() and me.eContents() method calls in EMF return the parent and children of element me respectively.

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. Back-ticks 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.

Operator	Description
+	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

Operator	Description
=	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.

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

Operator	Description
and	Returns the logical conjunction of the two expressions
or	Returns the logical disjunction of the two expressions
not	Returns the logical negation of the expression
implies	Returns the logical implication of the two expressions (see below)
xor	Returns true if only one of the involved expressions evaluates to true and false otherwise

The truth table for the implies logical operator is below.

Left	Right	Result
true	true	true
true	false	false
false	true	true
false	false	true

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⁴. 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;

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.

As of Epsilon 2.2, there is also the ?= shortcut assignment operator. This is useful for reassigning a variable if it is null. In other words, a ?= b is equivalent to if (a == null) a = b;.

var a = null;
var b = "result";
a ?= b;
assert(a == b);

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.

Since 2.5.0, you can optionally omit the type when referring to enumeration literals. All these options are available:

#vk_public
VisibilityEnum#vk_public
Model!#vk_public
Model!VisibilityEnum#vk_public

If a reference to an enumeration literal is ambiguous (i.e. there are several enumerations with a literal with the given name), EOL will report a warning and continue executing by assuming it refers to the first match.

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

Type	Default value
Integer	0
Boolean	false
String	""
Real	0.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.
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.
In line 8, we declare s1 as a Sequence of any type of value.
Line 9 declares s2 as a Sequence containing values of type Integer. Note that type parameters can be written as CollectionType<ValueType> or as CollectionType(ValueType).
Line 10 declares m1 as a Map where the keys and values can be of any type.
Line 11 declares m2 as a Map where the keys are Strings, and the values are Integers.

var i : Integer = 5;
var c : new Uml!Class;
//i = "somevalue";
if (c.isDefined()) {
  var i : String;
  i = "somevalue";
}
i = 3;
var s1 : Sequence;
var s2 : Sequence<Integer>;
var m1 : Map;
var m2 : Map(String, Integer);

Type parameters are only for documentation purposes in version 2.5.0

As of version 2.5.0, type parameters (e.g. <Integer> in Sequence<Integer>, or (String, Integer) in Map(String, Integer)) are only used for documentation purposes. EOL does not enforce that values of appropriate types are used during execution.

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

Signature	Description
inform(message : String)	Displays the specified message to the user
confirm(message : String, [default : Boolean]) : Boolean	Prompts the user to confirm if the condition described by the message holds
prompt(message : String, [default : String]) : String	Prompts the user for a string in response to the message
promptInteger(message : String, [default : Integer]) : Integer	Prompts the user for an Integer
promptReal(message : String, [default : Real]) : Real	Prompts the user for a Real
choose(message : String, options : Sequence, [default : Any]) : Any	Prompts the user to select one of the options
chooseMany(message : String, options : Sequence, [default : Sequence]) : Sequence	Prompts 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 IUserInput
implementation

Example of a command-line-based IUserInput
implementation

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.

Additional Resources¶

Additional resources about EOL are available here.

Parameters within square brackets are optional ↩
http://download.oracle.com/javase/8/docs/api/java/util/Formatter.html#syntax ↩
https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html ↩
For further examples of ternary operator, see https://github.com/eclipse-epsilon/epsilon/tree/main/tests/org.eclipse.epsilon.eol.engine.test.acceptance/src/org/eclipse/epsilon/eol/engine/test/acceptance/TernaryTests.eol ↩