Military Communications and Information Technology: A Trusted ...

Chapter 3: Information Technology for Interoperability and Decision...
213
guage, a good starting point is to create a domain model of the language [2], [16].
The grammar expressing concrete syntax should come out of the one describing
abstract syntax and should mainly populate it with concrete lexical elements and
specifics of the concrete language representation. Lexical elements (i.e. terminal
symbols of the CFG) are usually simple enough to be described by means of regular
expressions and recognized by finite-state automata [13], [15]. The grammar
describing the concrete syntax is directly used by the parser. Therefore, when designing
concrete syntax of a particular CL, it is necessary to cope with the following
challenges at the same time:
• The concrete syntax should be based on natural language constructions
commonly used in the particular context in the problem domain; otherwise
there would be a high risk that the users would refuse to use the DSL.
For that reason, the knowledge of the problem domain is very important.
• In order to be parseable, the CFG should be a deterministic context-free
grammar of a type corresponding to the particular type of parser used (most
often, LL(1) or LALR(1)). This requirement is connected with the unambiguousness
of the language generated by the CFG (although there are
parsing techniques that are able to cope with “controlled ambiguousness”
of the language being processed [13]) as well as the computational complexity
of the process of parsing: an arbitrary context-free language can be
parsed in O(n 3 ) time [15], but in the case of above mentioned deterministic
context-free grammars this time-complexity can be reduced to O(n), where
n represents the length of the language sentence being parsed.
Generally, there are two main strategies of parsing CLs – top-down, where
the parse tree of the given input is constructed from the root towards the leaves
and bottom-up, where the parse tree is constructed in the opposite direction
[2], [13], [17]. A typical type of top-down parser is a LL(1) parser, which
is supported by the ANTLR (ANother Tool for Language Recognition) or JavaCC
parser generators. Most commonly-used bottom-up parsers are LALR(1) parsers,
which are supported by Yacc/Bison parser generators. In general, bottom-up parsing
techniques are more powerful than the top-down ones in the sense of the class
of recognized languages [13].
For the reason of semantic processing we can populate the right-hand sides
of the productions (2) with semantic action symbols. Semantic action symbols play
an important role in the CL subsystem architecture (Fig. 2). The parser component
(e.g. of LALR(1) type) is the central controlling unit of the whole CL subsystem.
It uses the lexical analyzer to recognize lexical elements from the input. When
the parser comes across a semantic action symbol (while processing a particular
production or its part), it calls the corresponding semantic routine. Mutual communication
among semantic routines can be implemented by means of a semantic
stack maintained by the parser. Concrete techniques for implementing a semantic
stack depend on the type of parser [13].