Re: catcalls/convert

Dominique Colnet wrote:

> Raphael Mack wrote:
>
>> Hello, I played around with catcalls and found the interesting case: 
>> deferred class FOOD
>> inherit ANY
>>     redefine out end
>> feature
>>     out: STRING is do Result := "food" end
>> end
>> class SALAD, MEAT
>> inherit FOOD
>>     redefine out end
>> feature
>>     out: STRING is do Result := ["salad"|"meat"] end
>> end
>> class ANIMAL
>> feature
>>     eat(food: FOOD) is
>>         do
>>             io.put_string("ANIMAL eating " + food.out)
>>         end
>> end
>> class DOG
>> inherit ANIMAL
>>         redefine
>>             eat
>>         end
>> feature
>>     eat(food: MEAT) is
>>         do
>>             io.put_string("DOG eating " + food.out)
>>         end
>> end
>> class A
>>
>> creation
>>     make
>>
>> feature
>>     make is
>>         local
>>             a: ANIMAL
>>             m: MEAT
>>             s: SALAD
>>         do
>>             create {DOG}a
>>             create m     -- (XX)
>>             create s
>>             a.eat(s)
>>         end
>> end
>>
>> In this code everything seems to work: the compiler doesn't warn you 
>> and the dog really eats meat. If line XX is removed - what doesn't 
>> change anything - the program crashes at runtime with "Target Type 
>> "SALAD" is not valid". Of cause this is ok, since we triggered a 
>> catcall. With lin XX the compiler seems to optimize and "knows" in 
>> feature eat of class DOG we print the string "meat". This behavior is 
>> ok, because the whole construct is invalid, but for debugging it 
>> would be great if one would be warned or it would crash in both cases 
>> at runtime.
>
> Are you really using a fresh release of SmartEiffel ?
> I have checked your code on my working version and I get the correct
> error message at run-time:
>
>   Line : 9 column 34 in /home/colnet/RaphaelMack/dog.e.
>   *** Error at Run Time *** :
>   Target is not valid (not the good type).
>   Expected: "MEAT", Actual: "SALAD".
>
> By the way, it is amazing to see a student from Zurich using
> SmartEiffel ;-)
>
> Even if the (not so secret) flag -safety_check is far from beeing 
> perfect, the error message at compile time is interresting for this
> particular situation:
>   $ compile -safety_check a
>   ****** Warning: Unsafe call site (see also next warning).
>   Line 16 column 6 in A (/home/colnet/RaphaelMack/a.e):
>            a.eat(s)
>              ^
>   ------
>   ****** Warning: Unsafe covariant redefinition of argument number
>   1 (type "FOOD" redefined as "MEAT").
>   Line 3 column 2 in ANIMAL (/home/colnet/RaphaelMack/animal.e):
>      eat(food: FOOD) is
>      ^
>   Line 7 column 2 in DOG (/home/colnet/RaphaelMack/dog.e):
>      eat(food: MEAT) is
>      ^
>   ------
>   ****** 2 warnings.
>
> To help you to understand the probably strange behavior of the 
> compiler, keep in mind that, at time beeing, no dataflow analysis is 
> performed by
> the compiler.

Does SE currently use the method suggested in OOSC2 17.6?

To me it seems that if you get into dataflow analysis you might increase 
the accuracy by doing a deeper analysis, much like a chess program and 
at similar (potentially exponential) cost.
Do you have examples of interesting correct programs where the current 
safety_check would give false warnings and it is not easy to rewrite to 
avoid the warning?

Learning Java has improved my appreciation of Eiffel,
Urban Koistinen