Difference between revisions of "Talk:Agent problems"

Latest revision as of 02:05, 13 April 2007

Is CAT Call

--Schoelle 09:26, 21 November 2006 (CET)

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

--konradm

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?

--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]'

--manus 19:41, 11 April 2007 (CEST) Which options did you use and which rules of ECMA is supposed to trigger this?

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

--Seilerm 01:55, 12 April 2007 (CEST) Is there a plan to prevent this statically from happening?

--Ericb 08:11, 12 April 2007 (CEST): gec/gelint do that statically (i.e. at compilation time).

--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?

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