Talk:Agent problems - Revision history

Ericb at 11:05, 13 April 2007

2007-04-13T11:05:04Z

Seilerm: /* Is CAT Call */

2007-04-12T16:45:59Z

‎Is CAT Call

Ericb at 06:11, 12 April 2007

2007-04-12T06:11:56Z

Seilerm at 23:55, 11 April 2007

2007-04-11T23:55:56Z

Ericb at 21:44, 11 April 2007

2007-04-11T21:44:49Z

Manus at 17:41, 11 April 2007

2007-04-11T17:41:14Z

Ericb at 15:36, 11 April 2007

2007-04-11T15:36:02Z

Patrickr at 17:59, 21 November 2006

2006-11-21T17:59:17Z

Konradm: /* Is CAT Call */

2006-11-21T17:54:04Z

‎Is CAT Call

Schoelle at 08:26, 21 November 2006

2006-11-21T08:26:10Z

New page

== Is CAT Call ==

First comment: I assume you are missing a 'l_f := f'.

Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'. --[[User:Schoelle|Schoelle]] 09:26, 21 November 2006 (CET)

← Older revision		Revision as of 11:05, 13 April 2007
Line 30:		Line 30:
	--[[User:Seilerm\|Seilerm]] 18:45, 12 April 2007 (CEST)		--[[User:Seilerm\|Seilerm]] 18:45, 12 April 2007 (CEST)
	I was looking for more information about this. I haven't found anything on gobosoft.com (under construction so far :-). Anyway, the thing is that I thought it's not possible to do this analysis without false positives (or not reporting all CAT calls). I have this from another page which Matthias wrote ([[DynamicTypeSet]]). Is it ok if I would summarize this algorithm as stripped down program execution (not taking into account branches, etc.) which has to know the entire system?		I was looking for more information about this. I haven't found anything on gobosoft.com (under construction so far :-). Anyway, the thing is that I thought it's not possible to do this analysis without false positives (or not reporting all CAT calls). I have this from another page which Matthias wrote ([[DynamicTypeSet]]). Is it ok if I would summarize this algorithm as stripped down program execution (not taking into account branches, etc.) which has to know the entire system?
		+
		+	--[[User:Ericb\|Ericb]] 13:05, 13 April 2007 (CEST): The mechanism to use dynamic type sets to find CAT-calls is described in ETL2 (also the name CAT-call was invented later). Yes, there are false positives. But I'm not aware of any other proposed mechanism to get rid of CAT-calls that would not forbid cases which worked fine until today. The advantage of what is currently implemented in gec/gelint is that it works today (I'm not aware of any other proposed solution to get rid of CAT-calls that is currently implemented and available for people to use) and does not require people to rewrite all their Eiffel classes with new Eiffel syntax constructs and semantics. The drawback is that indeed it requires system level analysis. But gec takes advantage of this system level analysis to optimize the generated C code. So it's not really a problem for that particular non-incremental Eiffel compiler.

← Older revision		Revision as of 16:45, 12 April 2007
Line 27:		Line 27:

	--[[User:Ericb\|Ericb]] 08:11, 12 April 2007 (CEST): gec/gelint do that statically (i.e. at compilation time).		--[[User:Ericb\|Ericb]] 08:11, 12 April 2007 (CEST): gec/gelint do that statically (i.e. at compilation time).
		+
		+	--[[User:Seilerm\|Seilerm]] 18:45, 12 April 2007 (CEST)
		+	I was looking for more information about this. I haven't found anything on gobosoft.com (under construction so far :-). Anyway, the thing is that I thought it's not possible to do this analysis without false positives (or not reporting all CAT calls). I have this from another page which Matthias wrote ([[DynamicTypeSet]]). Is it ok if I would summarize this algorithm as stripped down program execution (not taking into account branches, etc.) which has to know the entire system?

← Older revision		Revision as of 06:11, 12 April 2007
Line 25:		Line 25:
	--[[User:Seilerm\|Seilerm]] 01:55, 12 April 2007 (CEST)		--[[User:Seilerm\|Seilerm]] 01:55, 12 April 2007 (CEST)
	Is there a plan to prevent this statically from happening?		Is there a plan to prevent this statically from happening?
		+
		+	--[[User:Ericb\|Ericb]] 08:11, 12 April 2007 (CEST): gec/gelint do that statically (i.e. at compilation time).

← Older revision		Revision as of 23:55, 11 April 2007
Line 22:		Line 22:

	--[[User:Ericb\|Ericb]] 23:44, 11 April 2007 (CEST): I ran gec with the default options. If I remember correctly ECMA says that either the compiler should report CAT-calls at compile time, or an exception should be raised at run-time. Gec chose the first alternative using the dynamic type set mechanism as a means to achieve that. The dynamic type set of `l_f' contains only one type: FUNCTION [A, TUPLE [B], C]. This is what I explicitly passed as argument to `foo' in the small program that I tried to compile with gec. So for that target type, the expected argument type for the call to `item' is TUPLE [B]. But what we get is an instance of TUPLE.		--[[User:Ericb\|Ericb]] 23:44, 11 April 2007 (CEST): I ran gec with the default options. If I remember correctly ECMA says that either the compiler should report CAT-calls at compile time, or an exception should be raised at run-time. Gec chose the first alternative using the dynamic type set mechanism as a means to achieve that. The dynamic type set of `l_f' contains only one type: FUNCTION [A, TUPLE [B], C]. This is what I explicitly passed as argument to `foo' in the small program that I tried to compile with gec. So for that target type, the expected argument type for the call to `item' is TUPLE [B]. But what we get is an instance of TUPLE.
		+
		+	--[[User:Seilerm\|Seilerm]] 01:55, 12 April 2007 (CEST)
		+	Is there a plan to prevent this statically from happening?

← Older revision		Revision as of 21:44, 11 April 2007
Line 20:		Line 20:

	'''--[[User:Manus\|manus]] 19:41, 11 April 2007 (CEST)''' Which options did you use and which rules of ECMA is supposed to trigger this?		'''--[[User:Manus\|manus]] 19:41, 11 April 2007 (CEST)''' Which options did you use and which rules of ECMA is supposed to trigger this?
		+
		+	--[[User:Ericb\|Ericb]] 23:44, 11 April 2007 (CEST): I ran gec with the default options. If I remember correctly ECMA says that either the compiler should report CAT-calls at compile time, or an exception should be raised at run-time. Gec chose the first alternative using the dynamic type set mechanism as a means to achieve that. The dynamic type set of `l_f' contains only one type: FUNCTION [A, TUPLE [B], C]. This is what I explicitly passed as argument to `foo' in the small program that I tried to compile with gec. So for that target type, the expected argument type for the call to `item' is TUPLE [B]. But what we get is an instance of TUPLE.

← Older revision		Revision as of 17:41, 11 April 2007
Line 18:		Line 18:
	to type 'TUPLE [B]' of formal argument in feature `item' in class 'FUNCTION [A,		to type 'TUPLE [B]' of formal argument in feature `item' in class 'FUNCTION [A,
	TUPLE [B], C]'		TUPLE [B], C]'
		+
		+	'''--[[User:Manus\|manus]] 19:41, 11 April 2007 (CEST)''' Which options did you use and which rules of ECMA is supposed to trigger this?

← Older revision		Revision as of 15:36, 11 April 2007
Line 12:		Line 12:

	I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type?		I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type?
		+
		+	--[[User:Ericb\|Ericb]] 17:36, 11 April 2007 (CEST): I tried to compiled this code with Gobo's gec/gelint and I got this error:
		+
		+	[CATCALL] class FOO (10,14): type 'TUPLE' of actual argument #1 does not conform
		+	to type 'TUPLE [B]' of formal argument in feature `item' in class 'FUNCTION [A,
		+	TUPLE [B], C]'

@@ Line 1: / Line 1: @@
 == Is CAT Call ==
 First comment: I assume you are missing a 'l_f := f'.
-Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'. --[[User:Schoelle|Schoelle]] 09:26, 21 November 2006 (CET)
+Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'.
 This article is in a very early state, so don't bother commenting to much on it. The intention is to list all the problems of the mechanism. Especially the fact that one has to type in a whole lot of type information for very little guarantees from the type system.
-I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type? --[[User:konradm|konradm]]
+I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type?

← Older revision		Revision as of 17:54, 21 November 2006
Line 4:		Line 4:

	Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'. --[[User:Schoelle\|Schoelle]] 09:26, 21 November 2006 (CET)		Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'. --[[User:Schoelle\|Schoelle]] 09:26, 21 November 2006 (CET)
		+
		+	This article is in a very early state, so don't bother commenting to much on it. The intention is to list all the problems of the mechanism. Especially the fact that one has to type in a whole lot of type information for very little guarantees from the type system.
		+
		+	I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type? --[[User:konradm\|konradm]]