Difference between revisions of "Talk:Agent problems"

(Is CAT Call)
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?

Revision as of 08:45, 12 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?