Catcall Test Proposal - Revision history

Peter gummer at 22:36, 6 November 2007

2007-11-06T22:36:55Z

← Older revision		Revision as of 22:36, 6 November 2007
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
	This article ~~describe~~ an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is a variation on an already discussed solution.		This article describes an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is a variation on an already discussed solution.

	== Syntax changes ==		== Syntax changes ==
Line 14:		Line 14:
	When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.		When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.

	{{Note\| This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get ~~2000~~ conformance errors.}}		{{Note\| This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get 2,000 conformance errors.}}

	== New validity rules ==		== New validity rules ==
	# The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types of the target type.		# The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types of the target type.
	# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.		# If one of the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.

	== Implementation issues==		== Implementation issues==
	The tricky part in the above is the ~~checks~~ for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has ~~not~~ corresponding type in the ancestor. For example:		The tricky part in the above is the check for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has no corresponding type in the ancestor. For example:
	<e>		<e>
	class A		class A
Line 48:		Line 48:
	end		end
	</e>		</e>
	In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>. This only works with single constraint, in the case of multiple constraints, our compiler will simply report a potential catcall due to a compiler limitation.		In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>. This only works with a single constraint; in the case of multiple constraints, our compiler will simply report a potential catcall due to a compiler limitation.

Manus at 01:35, 6 November 2007

2007-11-06T01:35:47Z

← Older revision		Revision as of 01:35, 6 November 2007
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
	This article describe an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is ~~merely~~ a variation of already ~~explored~~ solution.		This article describe an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is a variation on an already discussed solution.

	== Syntax changes ==		== Syntax changes ==
	A Type declaration can be preceded by the keyword <e>frozen</e>, that is to say:		A Type declaration can be preceded by the keyword <e>frozen</e>, that is to say:

	<e>		<e>
	a: frozen A</e>		a: frozen A</e>

	An actual generic parameter can be preceded by the keyword <e>variant</e>, that is to say:		An actual generic parameter can be preceded by the keyword <e>variant</e>, that is to say:

	<e>		<e>
	a: LIST [variant A]</e>		a: LIST [variant A]</e>

Manus: /* Implementation details */

2007-11-06T00:52:42Z

Implementation details

← Older revision		Revision as of 00:52, 6 November 2007
Line 22:		Line 22:
	# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.		# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.

	== Implementation ~~details~~ ==		== Implementation issues==
	The tricky part in the above is the checks for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has not corresponding type in the ancestor. For example:		The tricky part in the above is the checks for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has not corresponding type in the ancestor. For example:
	<e>		<e>

Manus: /* Implementation details */

2007-11-06T00:52:30Z

Implementation details

← Older revision		Revision as of 00:52, 6 November 2007
Line 50:		Line 50:
	end		end
	</e>		</e>
	In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>.		In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>. This only works with single constraint, in the case of multiple constraints, our compiler will simply report a potential catcall due to a compiler limitation.

Manus: /* New validity rules */

2007-11-06T00:51:48Z

New validity rules

← Older revision		Revision as of 00:51, 6 November 2007
Line 19:		Line 19:

	== New validity rules ==		== New validity rules ==
	# The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types.		# The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types of the target type.
	# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.		# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.

Manus: /* New conformance rules */

2007-11-06T00:51:14Z

New conformance rules

← Older revision		Revision as of 00:51, 6 November 2007
Line 16:		Line 16:
	When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.		When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.

	{{Note\| This ~~shows~~ to be the ~~most efficient~~ way to ~~validate~~ existing code. ~~For~~ the Eiffel batch compiler~~, if the default was the~~ existing rules, we would get about ~~40000~~ catcall violations. With the new ~~default~~, we only get 2000 conformance errors.}}		{{Note\| This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get 2000 conformance errors.}}

	== New validity rules ==		== New validity rules ==

Manus: /* New conformance rules */

2007-11-06T00:49:38Z

New conformance rules

← Older revision		Revision as of 00:49, 6 November 2007
Line 15:		Line 15:
	== New conformance rules ==		== New conformance rules ==
	When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.		When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.

			{{Note\| This shows to be the most efficient way to validate existing code. For the Eiffel batch compiler, if the default was the existing rules, we would get about 40000 catcall violations. With the new default, we only get 2000 conformance errors.}}

	== New validity rules ==		== New validity rules ==

Manus: Short description of what we have implemented

2007-11-06T00:47:36Z

Short description of what we have implemented

New page

[[Category:ECMA]]
This article describe an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is merely a variation of already explored solution.

== Syntax changes ==
A Type declaration can be preceded by the keyword <e>frozen</e>, that is to say:

<e>
a: frozen A</e>

An actual generic parameter can be preceded by the keyword <e>variant</e>, that is to say:

<e>
a: LIST [variant A]</e>

== New conformance rules ==
When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type.

== New validity rules ==
# The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types.
# If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>.

== Implementation details ==
The tricky part in the above is the checks for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has not corresponding type in the ancestor. For example:
<e>
class A
f (a: ANY) do end
end

class B [G]
inherit
A
redefine
f
end
feature
f (a: STRING) do end
end

class TEST
feature
make is
local
a: A
do
a.f ("My String")
end
end
end
</e>
In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>.