Minor-ECMA-problems - Revision history

Manus: Restored page content

2007-05-30T19:12:00Z

Restored page content

← 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.

Konradm at 00:57, 18 November 2006

2006-11-18T00:57:25Z

← 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.~~

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

2006-11-17T17:49:52Z

8.9.5 Validity: Precondition Export rule=

← Older revision		Revision as of 17:49, 17 November 2006
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		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		Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to
	which r is available:		which r is available:
	1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.		1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

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

2006-11-17T17:49:34Z

=Stuff that is not correctly formulated

← Older revision		Revision as of 17:49, 17 November 2006
Line 53:		Line 53:
	f (STRING): ANY		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:		Definition 8.5.1 should be changed to something with the following semantics:

Manus at 19:35, 31 October 2006

2006-10-31T19:35:24Z

← Older revision		Revision as of 19:35, 31 October 2006
Line 1:		Line 1:
			[[Category:ECMA]]

	=Precursor=		=Precursor=

Manus: Removed unexistent link to a page

2006-10-20T23:49:03Z

Removed unexistent link to a page

← Older revision		Revision as of 23:49, 20 October 2006
Line 66:		Line 66:

	====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]]		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		Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to
	which r is available:		which r is available:
	1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.		1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

Konradm: /* Unfolding */

2006-10-03T19:10:33Z

Unfolding

Show changes

Konradm: /* Unfolding */

2006-09-28T21:31:53Z

Unfolding

← Older revision		Revision as of 21:31, 28 September 2006
Line 26:		Line 26:

	====Motivation====		====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"		{\|border="0" cellpadding="2" cellspacing="0" align="center"

Konradm: /* Unfolding */

2006-09-28T20:36:44Z

Unfolding

← Older revision		Revision as of 20:36, 28 September 2006
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.		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:		We list all the possible unfoldings that occur in the standard:

Konradm: /* Unfolding */

2006-09-28T19:16:01Z

Unfolding

← Older revision		Revision as of 19:16, 28 September 2006
Line 7:		Line 7:
	We list all the possible unfoldings that occur in the standard:		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