More Typing Problems

[Maurizio Cimadamore]

On 07/09/10 22:55, Neal Gafter wrote:
> On Tuesday, September 7, 2010, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com>  wrote:
>    
>> On 07/09/10 14:55, Florian Weimer wrote:
>>      
>>> * Maurizio Cimadamore:
>>>
>>>
>>>        
>>>> with an actual argument of the kind:
>>>>
>>>> #(c){c.getName()}
>>>>
>>>>
>>>> So, given that there's no explicit type on 'c' and given that the method
>>>> 'select' is accepting *any* subtype of SAM<T,U>    for any U, I'm having
>>>> hard times in imagining an inference scheme that can infer something
>>>> meaningful (not Object) for 'c'.
>>>>
>>>>          
>>> This particular case isn't really a problem.  OCaml infers its type as
>>>
>>>     <    getName : 'a; ..>    ->    'a
>>>
>>> meaning "a function from an object which has got a getName method (and
>>> possibly other methods) returning a value of type 'a to a value of
>>> type 'a".  There are probably some issues if you treat SAM conversion
>>> as a variant of ML type ascription, but those can probably be solved.
>>>
>>>        
>> Smells of structural subtyping ;-) ?
>>      
> Indeed, generics with wildcards is structural subtyping.  The problem
> is that SAMs can't be generic (i.e. have the abstract method be
> generic), which excludes the ML solution.
>    
I'm referring to the classic notion structural subtyping [1] (very 
common in theoretical tractations); a structural type-system would give 
you the ability to denote "the type of an object that has some method 
called getName", as in the original email - in Java, you can't do that - 
sure you can mimick structural subtyping with generics by using a 
type-variable bound of some type A where A has a member named 'getName' 
- but that's not structural subtyping.

[1] - http://en.wikipedia.org/wiki/Structural_type_system