Revision as of 23:51, 11 May 2010

The ECMA standard makes several modifications to the Eiffel syntax. The general approach for the compilers is to extend the syntax rules, so that both old and new styles are supported. This happened with the new constructs like alias or assign. But it turns out this common way has to be broken sometime.

Mixed grammar

The way the old syntax can be updated so that the new one is accepted is to extend the old language grammar with the new constructs and to substitute old rules when the new ones cannot be used. For example, the ECMA grammar allows the following code:

item: INTEGER assign put
put (value: INTEGER)
   do
      ...
   end

Here the keyword assign declares an assigner command for the query item. But what if we also have a feature declaration like the following?

assign (value: INTEGER)
   do
      ...
   end

The compiler is smart enough to see that the keyword assign is not suitable in this context, but the corresponding identifier is just fine. So, it can treat the keyword as an identifier, because the source code is valid according to pre-ECMA rules.

Ambiguous grammar

Unfortunately the approach above does not work all the time when a new keyword is introduced. Let's consider the following code snippet:

class A
invariant
   a: b
   note
   c: d
end

In pre-ECMA Eiffel the class invariant consists of 3 assertion clauses with the second one without an associated tag. In ECMA Eiffel note is a keyword and therefore the class invariant has one clause followed by a new Notes construct with one entry. As a result it's impossible to have a grammar that allows to treat note either as an identifier or as a keyword using the surrounding context, because both variants are legal. The resulting grammar is ambiguous.

Transitional grammar

How can we get the best of the two worlds if we cannot have a grammar that covers both the old and the new syntax? The idea is to use a grammar that allows using both constructs with some limitations. Talking about the keyword note that comes more or less as a replacement for the keyword indexing, we allow using both as keywords and forbid using them as identifiers. This way the ambiguity is resolved though we cannot use note as an identifier anymore. The table below summarizes the behaviour using note/indexing transition as an example.

Affected constructs

The language constructs that are affected by the syntax option are listed in the table below.