Syntax level - Revision history

Alexander Kogtenkov: /* Affected constructs */ Described how this option affects the accepted constructs

2010-05-12T10:49:28Z

‎Affected constructs: Described how this option affects the accepted constructs

Alexander Kogtenkov: Added a section for the list of affected constructs

2010-05-12T08:51:43Z

Added a section for the list of affected constructs

Alexander Kogtenkov: Fixed a typo in category specification

2008-02-13T14:20:24Z

Fixed a typo in category specification

Alexander Kogtenkov: Added a page that explains why we need an option to specify the syntax used in the source code

2008-02-13T14:18:58Z

Added a page that explains why we need an option to specify the syntax used in the source code

New page

[[Category:Compiler]]
[[Category:Configuration]]
[[Categoty: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.
== 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:
<e>
item: INTEGER assign put
put (value: INTEGER)
do
...
end</e>
Here the keyword <e>assign</e> declares an assigner command for the query <e>item</e>. But what if we also have a feature declaration like the following?
<e>assign (value: INTEGER)
do
...
end</e>
The compiler is smart enough to see that the keyword <e>assign</e> 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:
<e>class A
invariant
a: b
note
c: d
end
</e>
In pre-ECMA Eiffel the class invariant consists of 3 assertion clauses with the second one without an associated tag. In ECMA Eiffel <e>note</e> 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 <e>note</e> that comes more or less as a replacement for the keyword <e>indexing</e>, 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 <e>note</e>/<e>indexing</e> transition as an example.
{|
! colspan="3" | Syntax compatibility level
|- align="center"
! width="30%" | Obsolete
! width="30%" | Transitional
! Standard
|- valign="top"
| <e>indexing</e> is used as a keyword
<e>note</e> is used as an identifier with an optional warning that it becomes a keyword in the future
| <e>indexing</e> is used as a keyword with an optional warning that it's an obsolete keyword that should be replaced with <e>note</e>
<e>note</e> is used as a keyword
| <e>indexing</e> is used as an identifier
<e>note</e> is used as a keyword
|}

← Older revision		Revision as of 10:49, 12 May 2010
Line 46:		Line 46:
	= Affected constructs =		= Affected constructs =
	The language constructs that are affected by the ''syntax'' option are listed in the table below.		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'''
		+	\|}

← Older revision		Revision as of 08:51, 12 May 2010
Line 44:		Line 44:
	<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.

@@ Line 1: / Line 1: @@
 [[Category:Compiler]]
 [[Category:Configuration]]
-[[Categoty:ECMA]]
+[[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.
 == Mixed grammar ==