Difference between revisions of "Syntax level"
(Added a page that explains why we need an option to specify the syntax used in the source code) |
m (→Affected constructs: Described how this option affects the accepted constructs) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[Category:Compiler]] | [[Category:Compiler]] | ||
[[Category:Configuration]] | [[Category:Configuration]] | ||
− | [[ | + | [[Category:ECMA]] |
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 <e>alias</e> or <e>assign</e>. But it turns out this common way has to be broken sometime. | 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 <e>alias</e> or <e>assign</e>. But it turns out this common way has to be broken sometime. | ||
== Mixed grammar == | == Mixed grammar == | ||
Line 43: | Line 43: | ||
| <e>indexing</e> is used as an identifier | | <e>indexing</e> is used as an identifier | ||
<e>note</e> is used as a keyword | <e>note</e> is used as a keyword | ||
+ | |} | ||
+ | = Affected constructs = | ||
+ | The language constructs that are affected by the ''syntax'' option are listed in the table below. | ||
+ | {| border="1" style="float: right; border-collapse: collapse; border-style: solid;" | ||
+ | |+ Legend | ||
+ | | style="color: navy;" | '''keyword''' | ||
+ | | Accepted as a keyword | ||
+ | |- | ||
+ | | style="color: blue;" | '''keyword''' | ||
+ | | Accepted as a keyword with a warning | ||
+ | |- | ||
+ | | style="color: teal;" | '''keyword''' | ||
+ | | Accepted as a keyword or if grammar permits as an identifier with a warning | ||
+ | |- | ||
+ | | style="color: gray;" | name | ||
+ | | Accepted as an identifier with a warning | ||
+ | |- | ||
+ | | style="color: black;" | name | ||
+ | | Accepted as an identifier | ||
+ | |} | ||
+ | |||
+ | {| border="1" style="border-collapse: collapse; border-style: solid;" | ||
+ | |+ Constructs affected by the option ''syntax'' | ||
+ | ! rowspan="2" style="valign: center;" | Release | ||
+ | ! colspan="4" | Option value | ||
+ | |- | ||
+ | ! Obsolete !! Transitional !! Standard !! Provisional | ||
+ | |- | ||
+ | ! rowspan="9" style="valign: center;" | [[EiffelStudio_6.6_Releases | 6.6]] | ||
+ | | style="color: gray;" | across | ||
+ | | style="color: gray;" | across | ||
+ | | style="color: gray;" | across | ||
+ | | style="color: teal;" | '''across''' | ||
+ | |- | ||
+ | | style="color: teal;" | '''assign''' | ||
+ | | style="color: teal;" | '''assign''' | ||
+ | | style="color: navy;" | '''assign''' | ||
+ | | style="color: teal;" | '''assign''' | ||
+ | |- | ||
+ | | style="color: gray;" | attached | ||
+ | | style="color: teal;" | '''attached''' | ||
+ | | style="color: navy;" | '''attached''' | ||
+ | | style="color: teal;" | '''attached''' | ||
+ | |- | ||
+ | | style="color: gray;" | attribute | ||
+ | | style="color: teal;" | '''attribute''' | ||
+ | | style="color: navy;" | '''attribute''' | ||
+ | | style="color: teal;" | '''attribute''' | ||
+ | |- | ||
+ | | style="color: gray;" | detachable | ||
+ | | style="color: teal;" | '''detachable''' | ||
+ | | style="color: navy;" | '''detachable''' | ||
+ | | style="color: teal;" | '''detachable''' | ||
+ | |- | ||
+ | | style="color: navy;" | '''indexing''' | ||
+ | | style="color: blue;" | '''indexing''' | ||
+ | | style="color: black;" | indexing | ||
+ | | style="color: black;" | indexing | ||
+ | |- | ||
+ | | style="color: navy;" | '''is''' | ||
+ | | style="color: blue;" | '''is''' | ||
+ | | style="color: black;" | is | ||
+ | | style="color: black;" | is | ||
+ | |- | ||
+ | | style="color: gray;" | note | ||
+ | | style="color: navy;" | '''note''' | ||
+ | | style="color: navy;" | '''note''' | ||
+ | | style="color: navy;" | '''note''' | ||
+ | |- | ||
+ | | style="color: gray;" | some | ||
+ | | style="color: gray;" | some | ||
+ | | style="color: gray;" | some | ||
+ | | style="color: teal;" | '''some''' | ||
|} | |} |
Latest revision as of 01:49, 12 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.
Syntax compatibility level | ||
---|---|---|
Obsolete | Transitional | Standard |
indexing is used as a keyword
|
indexing is used as a keyword with an optional warning that it's an obsolete keyword that should be replaced with note
|
indexing is used as an identifier
|
Affected constructs
The language constructs that are affected by the syntax option are listed in the table below.
keyword | Accepted as a keyword |
keyword | Accepted as a keyword with a warning |
keyword | Accepted as a keyword or if grammar permits as an identifier with a warning |
name | Accepted as an identifier with a warning |
name | Accepted as an identifier |
Release | Option value | |||
---|---|---|---|---|
Obsolete | Transitional | Standard | Provisional | |
6.6 | across | across | across | across |
assign | assign | assign | assign | |
attached | attached | attached | attached | |
attribute | attribute | attribute | attribute | |
detachable | detachable | detachable | detachable | |
indexing | indexing | indexing | indexing | |
is | is | is | is | |
note | note | note | note | |
some | some | some | some |