Minor-ECMA-problems - Revision history

Manus: Restored page content

2007-05-30T19:12:00Z

Restored page content

Konradm at 00:57, 18 November 2006

2006-11-18T00:57:25Z

Schoelle: /* 8.9.5 Validity: Precondition Export rule= */

2006-11-17T17:49:52Z

‎8.9.5 Validity: Precondition Export rule=

Schoelle: /* =Stuff that is not correctly formulated */

2006-11-17T17:49:34Z

‎=Stuff that is not correctly formulated

Manus at 19:35, 31 October 2006

2006-10-31T19:35:24Z

Manus: Removed unexistent link to a page

2006-10-20T23:49:03Z

Removed unexistent link to a page

Konradm: /* Unfolding */

2006-10-03T19:10:33Z

‎Unfolding

Show changes

Konradm: /* Unfolding */

2006-09-28T21:31:53Z

‎Unfolding

Konradm: /* Unfolding */

2006-09-28T20:36:44Z

‎Unfolding

Konradm: /* Unfolding */

2006-09-28T19:16:01Z

‎Unfolding

← Older revision	Revision as of 19:12, 30 May 2007
Line 1:	Line 1:
	+	[[Category:ECMA]]
	+	=Precursor=

	+	The current definition of the Precursor semantics in the ECMA standard (8.10.11)
	+
	+	=Agent types=
	+	==Motivation==
	+	The classes ROUTINE, PROCEDURE, FUNCTION and the new class PREDICATE do not nicely fit in to the Eiffel language. Reasons:
	+	* They do not reflect the fact, that an agent can refer an attribute. An attribute is not a ROUTINE.
	+	* They do contradict the uniform access principle.
	+	* They are difficult to define. It is difficult to understand, why it is so difficult to define an agent type when it is so easy in functional languages!
	+	** Specially the first generic Parameter of ROUTINE is difficult to understand and, if I am not wrong, never used.
	+	* The standard conformance rules simply do not work nice for agent types. They introduce a type hole that can only be detected at runtime, and even then, only if precondition assertions are enabled. Other than cat calls this typing problem doesn't give the language more power.
	+
	+	==An other mechanism:==
	+
	+	I will give an example of an other mechanism:
	+
	+	Instead of writing
	+
	+	<code>[N, eiffel]
	+	f: FUNCTION [ANY, TUPLE [STRING], INTEGER]
	+	</code>
	+
	+	we could write
	+	<code>[N, eiffel]
	+	f (STRING): INTEGER
	+	</code>
	+
	+	Calling this f would be easy:
	+
	+	i: INTEGER
	+	...
	+	i := f ("hello")
	+
	+	We could also write:
	+
	+	i: INTEGER
	+	...
	+	i := agent f ("hello")
	+
	+
	+
	+
	+
	+
	+	Instead of writing:
	+
	+	f: FUNCTION [ANY, TUPLE [STRING], ANY]
	+
	+	we would write:
	+
	+	f (STRING): ANY
	+
	+	==Stuff that is not correctly formulated==
	+	Definition 8.5.1 should be changed to something with the following semantics:
	+
	+	====8.5.1 Definition: Inherited, immediate; origin; redeclared; replicated introduce====
	+
	+	Any feature f of a class C is of one of the following four kinds:
	+
	+	# If C obtains f from one of its parents, f is an inherited feature of C. In this case any declaration of f in C (adapting the original properties of f for C) is a redeclaration.
	+	# If a declaration appearing in C applies to a feature that is not inherited, the feature is said to be immediate in C. Then C is the origin (short for “class of origin”) of f, and is said to introduce f.
	+
	+
	+	====8.9.5 Validity: Precondition Export rule====
	+	A Precondition of a feature r of a class S is valid if and only if every feature f appearing in every
	+	Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to
	+	which r is available:
	+	1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

← Older revision		Revision as of 00:57, 18 November 2006
Line 1:		Line 1:
−	~~[[Category:ECMA]]~~
−	~~=Precursor=~~

−	~~The current definition of the Precursor semantics in the ECMA standard (8.10.11)~~
−
−	~~=Agent types=~~
−	~~==Motivation==~~
−	~~The classes ROUTINE, PROCEDURE, FUNCTION and the new class PREDICATE do not nicely fit in to the Eiffel language. Reasons:~~
−	* They do not reflect the fact, that an agent can refer an attribute. An attribute is not a ROUTINE.
−	* They do contradict the uniform access principle.
−	* They are difficult to define. It is difficult to understand, why it is so difficult to define an agent type when it is so easy in functional languages!
−	** Specially the first generic Parameter of ROUTINE is difficult to understand and, if I am not wrong, never used.
−	* The standard conformance rules simply do not work nice for agent types. They introduce a type hole that can only be detected at runtime, and even then, only if precondition assertions are enabled. Other than cat calls this typing problem doesn't give the language more power.
−
−	~~==An other mechanism:==~~
−
−	~~I will give an example of an other mechanism:~~
−
−	~~Instead of writing~~
−
−	~~<code>[N, eiffel]~~
−	~~f: FUNCTION [ANY, TUPLE [STRING], INTEGER]~~
−	~~</code>~~
−
−	~~we could write~~
−	~~<code>[N, eiffel]~~
−	~~f (STRING): INTEGER~~
−	~~</code>~~
−
−	~~Calling this f would be easy:~~
−
−	~~i: INTEGER~~
−	~~...~~
−	~~i := f ("hello")~~
−
−	~~We could also write:~~
−
−	~~i: INTEGER~~
−	~~...~~
−	~~i := agent f ("hello")~~
−
−
−
−
−
−
−	~~Instead of writing:~~
−
−	~~f: FUNCTION [ANY, TUPLE [STRING], ANY]~~
−
−	~~we would write:~~
−
−	~~f (STRING): ANY~~
−
−	~~==Stuff that is not correctly formulated==~~
−	~~Definition 8.5.1 should be changed to something with the following semantics:~~
−
−	~~====8.5.1 Definition: Inherited, immediate; origin; redeclared; replicated introduce====~~
−
−	~~Any feature f of a class C is of one of the following four kinds:~~
−
−	~~# If C obtains f from one of its parents, f is an inherited feature of C. In this case any declaration of f in C (adapting the original properties of f for C) is a redeclaration.~~
−	# If a declaration appearing in C applies to a feature that is not inherited, the feature is said to be immediate in C. Then C is the origin (short for “class of origin”) of f, and is said to introduce f.
−
−
−	~~====8.9.5 Validity: Precondition Export rule====~~
−	~~A Precondition of a feature r of a class S is valid if and only if every feature f appearing in every~~
−	~~Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to~~
−	~~which r is available:~~
−	~~1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.~~

@@ Line 64: / Line 64: @@
-====8.9.5 Validity: Precondition Export rule=====
+====8.9.5 Validity: Precondition Export rule====
 A Precondition of a feature r of a class S is valid if and only if every feature f appearing in every
 Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to
 which r is available:
 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

@@ Line 53: / Line 53: @@
 f (STRING): ANY
-==Stuff that is not correctly formulated=
+==Stuff that is not correctly formulated==
 Definition 8.5.1 should be changed to something with the following semantics:

@@ Line 1: / Line 1: @@
+[[Category:ECMA]]
-−
 =Precursor=

@@ Line 26: / Line 26: @@
 ====Motivation====
-There are several situations in which the ECMA standard uses unfolded forms as a vehicle to describe semantics. When this unfolded forms need names, like in Precursor, inline agents and not isolated features. These names have an influence on the semantics of the system. An example:
+There are several situations in which the ECMA standard uses unfolded forms as a vehicle to describe semantics. When this unfolded forms need names, like in Precursor, inline agents and not isolated features, hese names have an influence on the semantics of the system. An example:
 {|border="0" cellpadding="2" cellspacing="0" align="center"

@@ Line 3: / Line 3: @@
 When class ''D'' inherits from class ''B'' there is one very critical question. What form (in respect to unfolding) of ''B'' is taken into account for the inheritance semantics. Without an argument I state that it should be its completely unfolded form.
-This said we can state that ''D'' inherits from the completely unfolded class ''B''. It remains to be specified in what order ''D'' is unfolded.
+This said we can state that ''D'' inherits from the completely unfolded class ''B''. It remains to be specified in what order ''D'' is unfolded. We will try to construct a partial order.
 We list all the possible unfoldings that occur in the standard:

@@ Line 7: / Line 7: @@
 We list all the possible unfoldings that occur in the standard:
-* 8.5.24 Definition: Unfolded form of a possibly multiple declaration
+# 8.6.6 Definition: Unfolded Inheritance Part of a class
-* 8.6.6 Definition: Unfolded Inheritance Part of a class
+# 8.5.24 Definition: Unfolded form of a possibly multiple declaration
-* Pre post conditions and invariants?
+# 8.9.13 Definition: Unfolded feature list of an Only clause
-* 8.9.13 Definition: Unfolded feature list of an Only clause
+# 8.9.14 Definition: Unfolded Only clause
-* 8.9.14 Definition: Unfolded Only clause
+# 8.9.24 Definition: Local unfolded form of an assertion
-* 8.9.24 Definition: Local unfolded form of an assertion
+# 8.10.2 Definition: Unfolded form of an assertion
-* 8.10.2 Definition: Unfolded form of an assertion
+# 8.10.11 Definition: Relative unfolded form of a Precursor
-* 8.10.11 Definition: Relative unfolded form of a Precursor
+# 8.10.13 Definition: Unfolded form of a Precursor
-* 8.10.13 Definition: Unfolded form of a Precursor
+# 8.10.30 Definition: Unfolded redeclaration
-* 8.10.30 Definition: Unfolded redeclaration
+# 8.17.9 Definition: Unfolded form of a multi-branch
-* 8.17.9 Definition: Unfolded form of a multi-branch
+# 8.17.10 Definition: Unfolded form of an interval
-* 8.17.10 Definition: Unfolded form of an interval
+# 8.20.5 Definition: Unfolded Creators part of a class
-* 8.20.5 Definition: Unfolded Creators part of a class
+# 8.20.14 Definition: Unfolded form of a creation instruction
-* 8.20.14 Definition: Unfolded form of a creation instruction