Talk:Agent problems

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.