Extended, normalised Backus-Naur Forms

The syntax of a formal language is usually dened by a grammar of some sort. In languages that occur in software engineering practice the syntax is context-free. We, therefore, need not consider languages at higher-levels of the Chomsky hierarchy. Most often a Backus-Naur Form (BNF) is used for dening context free grammars. We found plain BNFs to be not expressive enough. As already discussed in [ES89] their way of dening list, alternative and optional increments is not very concise. We, therefore, extend BNFs to deal with these concerns more eciently. For the later use of extended BNFs, in particular as an input for the genera- tion of specications at lower levels of abstraction, it is necessary to normalise the extended BNFs. The language denition for our extended and normalised BNF (ENBNF) is displayed in Figure 6.1. The notation is plain BNF.

<enbnf> ::= <production-list> <production-list>::= <production>

<production-list>::= <production> <production-list> <production> ::= <symbol> "::=" <alternative> <production> ::= <symbol> "::=" <structure> "." <production> ::= <symbol> "::=" "|" <structure> "." <production> ::= <symbol> ":" <reg-exp> "."

<production> ::= <symbol> ":" "|" <reg-exp> "." <alternative> ::= <symbol> "|" <alternative> <alternative> ::= <symbol> "|" <symbol> <structure> ::= <component-list> <component-list> ::= <component>

<component-list> ::= <component> <component-list> <component> ::= <keyword>

<component> ::= <symbol> <component> ::= <list>

<list> ::= "{" <symbol> "}" <opt_delimiter> <opt_delimiter> ::=

<opt_delimiter> ::= "(" <keyword-list> ")" <keyword-list> ::= <keyword>

<keyword-list> ::= <keyword> <keyword-list> <keyword> : ["].*["]

<reg-exp> : ['].*[']

<symbol> : [a-zA-Z_][a-zA-Z_-0-9]*

An ENBNF consists of a list of productions. The normalisation of the EBNF is enforced by the language syntax. It denes ve dierent kinds of productions: alternatives, structures, optional structures regular expressionsand optional regular expressions. A symbol is terminal, if it is dened by a production with a regular expression on the right-hand side, otherwise it is non-terminal. Alternative productions provide for a choice of a number of non-terminal symbols. Note that structures or lists as alternatives are not supported in this normalisation. Structure productions contain symbols and keyword denitions. A structure production is a list production if it contains an element that has been produced by production <list>. This

list might then dene delimiter items that separate several list elements. A static semantic constraint will ensure that only further keywords are included on the right-hand side of these productions. Regular expressions dene the lexical syntax of a terminal symbol. Finally, optional productions provide for a choice between the empty string and a structure or the empty string and a regular expression.

Obviously syntax denitions dened in ENBNFs must obey certain static semantic constraints. These are as follows:

SV1:

Each symbol used on the right-hand side of a production must be declared by a produc- tion where it appears on the left-hand side, otherwise the grammar would be incomplete.

SV2:

Symbols must be declared only once, otherwise there would be alternatives in the gram- mar that are not dened as alternative productions in the ENBNF.

SV3:

If a structure production contains a list on the right-hand side, there must not be any other symbols included in the component list of that production.

Throughout this chapter, we will take examples from the Groupie module interface editor. An excerpt of the syntax of the module interface denition language supported by Groupie is dened as an ENBNF below.

Module ::= ADTModule | FModule | ADOModule | TCModule . ADTModule ::= "DATATYPE" "MODULE" ModName ";"

Comment

"EXPORT" "INTERFACE" "TYPE" TypeName ";" OperationList "END" "EXPORT" "INTERFACE" ImportInterface

"END" "MODULE" ModName "." . OperationList ::= {Operation} .

Operation ::= Function | Procedure .

Function ::= "FUNCTION" OpName ParameterList ":" UsingType ";" Comment . Procedure ::= "PROCEDURE" OpName ParameterList ";" Comment .

ParameterList ::= | "(" {Parameter}(";") ")" . Parameter ::= InParameter | InOutParameter . InParameter ::= "IN" ParName ":" UsingType . InOutParameter::= "INOUT" ParName ":" UsingType . ... ModName ::= '[A-Za-z][A-Za-z0-9]*' . ParName ::= '[A-Za-z][A-Za-z0-9]*' . TypeName ::= '[A-Za-z][A-Za-z0-9]*' . OpName ::= '[A-Za-z][A-Za-z0-9]*' . UsingType ::= '[A-Za-z][A-Za-z0-9]*' . Comment ::= | '/"*"([^*/]|[^*]"/"|"*"[^/])*"*"/' . ...

The alternative production Module denes the four dierent types of modules supported by

the Groupie module interface denition language. The next structure production denes the syntax of an ADT module in more detail. In particular, an ADT module has children for

the module name, a comment, an exported type, an exported operation list and an import interface. As examples of list productions, consider operation lists and parameter lists. Notice how we used the delimiter construct to dene the way parameters are delimited. Note also that parameter lists as well as comments are optional productions. Finally, comments and several kinds of identiers are dened by a number of regular expression productions.

Summarising the discussion, ENBNFs are suitable for dening the abstract and concrete syntax of a language that is to be supported by a syntax-directed editor. The ENBNF denes the syntax in a very concise way and in addition the dierent productions identify the increment classes that have to be rened. It thus serves, at a very high-level of abstraction, as a starting point for a tool development. However, it does not yet dene any semantic relationships. We, therefore, continue at a lower level of abstraction with the denition of a language that serves this purpose.

In document Tool specification with GTSL (Page 130-132)