# Syntax Reference

The following chapter serves as a reference for the concrete syntax of MWE2. The building blocks of a module will be described in a few words.

MWE2 is not sensitive to white-space and allows to define line-comments and block comments everywhere. The syntax is the same as one is used to from the Java language:

`// This is a comment
/*
This is another one.
*/
`

Every name in MWE2 can be a fully qualified identifier and must follow the Java conventions. However, in contrast to Java identifiers it is not allowed to use German umlauts or Unicode escape sequences in identifiers. A valid ID-segment in MWE2 starts with a letter or an underscore and is followed by any number of letters, numbers or underscores. An identifier is composed from one or more segments which are delimited by a ‘.’ dot.

`Name: ID ('.' ID)*;
ID: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;
`

MWE2 does not use a semicolon as statement delimiter at any place.

### Module

A module consists of four parts. The very first statement in a *.mwe2 file is the module declaration. The name of the module must follow the naming convention for Java classes. That MWE2 file’s name must therefore be the same as the last segment of the module-name and it has to be placed in the appropriate package of a Java source path.

It is allowed to define any number of import statements in a module. Imports are either suffixed by a wild-card or concrete for a class or module. MWE2 can handle relative imports in case one uses the wild-card notation:

`'import' name '.*'?
`

### Property

The list of declared properties follows the optional import section. It is allowed to define modules without any properties.

Each declared property is locally visible in the module. It furthermore defines an assignable feature of the module in case one refers to it from another module. Properties may either have a default value or they are considered to be mandatory. If the type of property is omitted it will be inferred from the default value. The default type of a property is java.lang.String so if no default value is available, the property is mandatory and of type String.

There are four types of values available in MWE2. One may either define a string, boolean or component literal or a reference to a previously defined property.

### Component

The last part of a module is the root component. It defines the externally visible type of the module and may either be created from a Java type or from another module.

The type of the component can be derived in many cases except for the root component. That’s why it’s optional in the component literal. If no type is given, it will be inferred from the left side of the assignment. The assigned feature can either be a declared property of the module or a set- or add-method of a Java class.

Components can be named to make them referable in subsequent assignments. Following the ':' keyword, one can define an identifier for the instantiated component. The identifier is locally visible in the module and any assignment that is defined after the named component can refer to this identifier and thereby point to exactly the instantiated object.

The next option for a component is auto-inject. If this modifier is set on a component, any available feature of the component that has the same name as a property or previously created named component will be automatically assigned.

The core of a component is the list of assignments between the curly braces. An arbitrary number of values can be set on the component by means of feature-to-value pairs.

The available constructs on the right hand side of the assignment are the same as for default values for properties.

### String Literals

String values are likely to be the most used literals in MWE2. There is a convenient syntax for string concatenation available due to the high relevance in a description object composition and configuration language. MWE2 strings are multi-line strings and can be composed of several parts.

`var aString = 'a value'
var anotherString = 'It is possible to embed ${aString} into
a multi-line string'
`

This is especially convenient for path-substitution if one defines e.g. a common root directory and wants to specify other paths relative to the base.

There are two different delimiters available for strings. Users are free to either use single- or double-quotes to start and end strings. If a certain string contains a lot of single-quotes one would better choose double-quotes as delimiter and vice versa. There is no semantic difference between both notations.

The escape character in MWE2 is the back-slash "\". It can be used to write line-breaks or tabular characters explicitly and to escape the beginning of substitution variables ${ and the quotes itself. Allowed escape sequences are:

`\n .. line break
\r .. carriage return
\t .. tabular character
\' .. single-quote (can be omitted in double-quoted strings)
\" .. double-quote (can be omitted in single-quoted strings)
\${ .. escape the substitution variable start ${
\\ .. the back-slash itself
`

Other escape sequence are illegal in MWE2 strings.

### Boolean Literals

MWE2 has native support for the boolean type. The literals are true and false.

### References

Each assigned value in MWE2 either as default for properties or in a component assignment can be a reference to a previously declared property or named component. The can be referenced intuitively by their name.