The main goal when developing a programming language is to make programming more efficient. Ideally, one programming language should provide the suitable level of abstraction which allows solutions to be expressed naturally and hides unnecessary details. Furthermore, it should be expressive enough, should provide guarantees on the prop- erties which are important in the domain and it should also have precise semantics to enable formal reasoning about a program.
Domain Specific Languages (DSLs), according to (Bet11), are small languages dedicated to a particular aspect of a software system. Hence, DSLs are designed with an aim to improve programmers’ productivity in a particular domain compared to General Purpose Languages (GPLs) such as Java or C.
Implementing a DSL at least consists of a series of procedures which would allow one machine to perform lexical analysis, syntax analysis or parsing, and finally interpret program or generate the code in another language.
In the lexical analysis, an input textual file representing the source code is decomposed into atomic elements or tokens which are of four types: keywords, identifiers, symbols and literals. For example, a variable declaration int value = 100; contains a keyword int, an identifier value, a literal 100 and symbols ’;’ and ’=’. Lexical analysis is followed by the syntax analysis which for an input construct checks whether it respects the syntactic structure specified by the language grammar. The main idea of the grammar is to describe the concrete syntax and how it is mapped to an in-memory representation, i.e., the semantic model. This model is produced during parsing and it is called the Abstract Syn- tax Tree (AST). Upon successful completion of the previous phases, such program is ready to be interpreted or alternatively it can be used as in input to a code generator to generate code in a different language.
2.3.1
The X
TEXTFramework
XTEXT(Xte16) is an open source framework for developing DSLs. Im- plementing a DSL starts with specifying the language grammar and can include additional specifications for program verification, code genera- tor or interpreter, type checking and scoping. XTEXTpromotes a Java- like programming language, Xtend, to write parts of a DSL implemen- tation. Additionally, XTEXTprovides integration of a DSL in the Eclipse
Integrated Development Environment (IDE). The main advantages that come along with an IDE support are syntax highlighting, that improves code visibility through coloring and formatting keywords, background parsing, which continuously checks the program syntax and marks er- rors, content assistant, which provides auto completing mechanism, and hyperlinking, which permits navigation between references in a program.
The Grammar Language
The grammar language of XTEXTis itself a DSL designed for describing other DSLs. Essentially, grammar specification of a languages establishes a connection between the language syntax and its semantic model.
The body of a grammar file is a list of grammar rules. For example, rule ID:
1 terminal ID:
2 (’ˆ’)?(’a’..’z’|’A’..’Z’|’_’) (’a’..’z’|’A’..’Z’|’_
,→ ’|’0’..’9’)*;
specifies that a token ID can start with optional ” ˆ ” character, fol- lowed by a letter or underscore, followed by an arbitrary number of let- ters, underscores and numbers. Symbols *, + and ? indicate the cardi- nality of expressions in the brackets; operator * means zero or greater, + indicates one or greater, while ? indicates cardinality zero or one. If no operator is used the assumed cardinality is exactly one. Rule ID is a terminal rule in that it contains only elementary symbols, such as letters, numbers and other characters.
Apart from terminal rules, two other types of rules are data type and production rules. Data type rules, like terminal rules, do not contain fea- ture assignments, but may use other rules. On the other hand, production rules contain one or more feature assignments and yield an instance in the AST of the parsed program.
Listing 2.10 shows a grammar snippet which defines two rules.
Listing 2.10:Sample grammar
1 grammar org.xtext.example.Sample
2 with org.eclipse.xtext.common.Terminals
3 Program:
4 (’package’ name = QualifiedName ’;’)?
5 classes += Class*
6 ;
7 QualifiedName: ID (’.’ ID)* ;
QualifiedNamerule exemplifies a data type rule, while Program is an example of a production rule as it contains a feature assignment, i.e., name = QualifiedName. Moreover, the first line declares the name of the language and of the grammar, while the second line states the use of the built-in grammar Terminals which defines basic rules, such as the
IDrule, which can be used in the grammar, as in the definition of the QualifiedNamerule.
Each rule has a return type. If it is not explicitly stated, it is implied that the type’s name equals the rule’s name. As Program is the starting rule, it defines the type of the root element of the syntax tree. Types of features name and classes are inferred from the right hand sides of as- signments and correspond respectively to QualifiedName and Class. Moreover, operator += indicates a collection of zero or more objects of type Class to be stored in feature classes.
XTEXTallows declaration of cross-links in the grammar. Rule:
1 Variable:
2 ’var’ name = ID ’:’ type = [Type];
contains a cross-reference pointing to a Type, meaning that for a fea- ture type only instances of Type are allowed. Cross-reference resolution involves scoping. Typically, a DSL designer implement scopes that define target candidates for the given cross-reference. Such references in the source code are validated during parsing. An additional feature to name can be used to record a boolean value which captures is variable type is specified or not, as in the following:
1 Variable:
2 ’var’ name = ID (istyped ?=’:’ type = [Type])?;
Once a language grammar is defined, a DSL designer may specify an interpreter that works on the AST or a code generator to translate the one program to another or generate a configuration file.
Chapter 3
The Memory Consistency
Guarantees
Several concepts from the domain of memory models are essential for understanding our work on replica-aware programming in RepliKlaim and SharedX10. This chapter starts by providing a short introduction to the theory of the memory consistency models in Section 3.1. Section 3.2 presents a brief overview of the consistency guarantees in high-level pro- gramming languages, and provides an example that promotes the pro- gramming styles introduced in RepliKlaim and SharedX10. Section 3.3 outlines several ubiquitous consistency models for replicated data in replicated systems (e.g., distributed systems with replicas), and presents formalizations of the two consistency models for replicated data sup- ported in RepliKlaim and SharedX10.