(Internal classification: major example)

Reference paper: “Domain-Specific Aspect Languages for Modularizing Crosscutting Concerns in Grammars” Damijan Rebernak, Marjan Mernik, Hui Wu, Jeff Gray, In IET Software, To Appear

The reference paper discusses both AspectG and AspectLISA

The definition of programming languages (grammars) and compiler construction. An important problem in this area is the modularity, reusability and extensibility of a language specification. AOSD is used here to modularize semantic concerns that crosscut many language components described in the grammar.

From the reference paper: “Within a language specification, modularization is typically based on language syntax constructs (e.g., declarations, expressions and commands). Adding new functionality to an existing language sometimes can be done in a modular way by providing separate grammar productions associated with the extension. For example, additions made to specific types of expressions within a language can be made by changing only those syntax and semantic productions associated with expressions. […] there are certain types of language extensions (e.g., type checking, environmnent propagation, code generation) that may require changes in many (if not in all) of the language productions represented in the grammar. […] the various concerns associated with each language tool are often scattered throughout the core language specification. Such language extensions to support tool generation emerge as aspects that crosscut language components”

LISA is compiler-compiler that generates a language compiler and a set of related tools starting from an attribute grammar-based language specification. This specification is programmed in the LISA language: a DSL “designed to support modularity, reusability and incremental language development through mechanisms like multiple inheritance and templates in [attribute grammars] […] The main weakness of multiple attribute grammar inheritance is the lack of modularization of similar semantics for syntactic productions that are not under the inheritance relation. This limitation is solved by introducing templates […] A template […] is a polymorphic abstraction of a semantic rule or syntactic production parameterized with attribute occurrences that can be associated with many production rules with different non-terminal and terminal symbols.” (Rebernak et al).

The intent of AspectLISA, an extension to LISA, is to allow modularisation of concerns which are hard to implement using inheritance due to their cross-cutting nature. Examples of this are type checking, environment propagation and code generation.

Comparing AspectLISA and AspectG in one line: AspectLISA allows for extension of the base language, AspectG allows for the definition of new tools on an existing grammar.

• JPM: Domain-Specific : Join points in AspectLISA are the production rules of the language specification.
• AM: Domain-Specific : The advice are semantic rules.

Note that it could be vaguely argued that the advice model is general-purpose with respect to the base language, as it is the same kind of code that is written in the base language.

AspectLISA pointcuts match rules or productions in the language specification. Two kinds of wildcards may be used here:

• “..” matches 0 or more terminals or non-terminals and can be used to specify right-hand side matching rules,
• “*” matches parts or whole literals representing a terminal or non-terminal symbol

Advice are similar to templates in attribute grammars: “advice are polymorphic abstractions of semantic rules parameterized with any number of terminals, non-terminals or attributes.”(Rebernak et.al.) There is however a crucial difference in that advice define additional semantics only through extension or refinement of the existing syntax. Templates do change the syntax level of the language specification.

The order of application of semantic rules is determined by the AspectLISA compiler, therefore there is no specification of before or after, and neither is there a need for aspect ordering to be defined.

These examples are taken from the 2006 paper with the same name as the reference paper¹⁾.

As the base language: LISA is a DSL, we first include an example of code in LISA. The same example is used in AspectG.

language Robot { 
lexicon { 
   Commands left | right | up | down 
   ReservedWord begin | end 
   ignore [\0x0D\0x0A\ ] // skip whitespaces 
} 
rule start { 
   START ::= begin COMMANDS end compute { 
      START.outp = COMMANDS.outp; // robot position in the beginning 
      COMMANDS.inp = new Point(0, 0); }; 
}
rule move { // each command changes one coordinate 
   COMMAND ::= left compute { 
      COMMAND.outp = new Point((COMMAND.inp).x-1,(COMMAND.inp).y); }; 
   COMMAND ::= right compute { 
      COMMAND.outp = new Point((COMMAND.inp).x+1,(COMMAND.inp).y); }; 
   COMMAND ::= up compute {
      COMMAND.outp = new Point((COMMAND.inp).x,(COMMAND.inp).y+1); };
   COMMAND ::= down compute { 
      COMMAND.outp = new Point((COMMAND.inp).x,(COMMAND.inp).y-1); }; 
} [...] }

The following code uses a pointcut that matches all productions with COMMAND as the left-hand non-terminal, and adds a reset to a time counter to all productions.

pointcut Time<COMMAND> *.move : COMMAND ::= * ;

advice TimeSemantics<C> on Time { C.time=1; } 

AspectLISA is only able to add extra semantics to an existing language specification. It is not specified whether the semantic rules in the advice are restricted in any form.

The aspect weaver for AspectLISA is an integral part of the LISA compiler, taking place after its parsing phase. The algorithm for weaving merges the semantic rules for each advice with the production rules of the language before generating the compiler and/or language tools. The algorithm is outlined in the reference paper.