Re: [scala] Conformance to bounds in higher-order type parameters

> Hi Vladimir,
> Thanks for raising these interesting questions!
>
> Essentially, these type aliases are performing "kind casts". You're right
> that all these type applications are well-kinded; the kind conformance
> algorithm simply isn't sophisticated enough (yet) to insert these kind
> casts
> automatically.
>
> Could you please file a ticket to request this enhancement and assign it to
> me?
>
> thanks!
> adriaan
>
> On Tue, Jun 16, 2009 at 3:19 PM, Christos KK Loverdos
> <loverdos@...>wrote:
>
>> Hmm...I think the behaviour is beyond my knowledge and I have to read the
>> Spec. For example I am not sure how I can interpret the type definitions
>> you
>> give: are they aliases or constraints?
>>
>>
>> On Jun 16, 2009, at 2:42 PM, Vladimir Reshetnikov wrote:
>>
>>  Hi Christos,
>>>
>>> Constraints on nested type parameters of a higher-order type parameter
>>> work in backwards direction: it is OK to substitute a type constructor
>>> with unconstrained nested type parameters instead of a higher-order
>>> type parameter with constrained nested type parameters.
>>>
>>> In my example, it is possible to work around the current compiler
>>> behavior with type aliases:
>>>
>>> ////////////////////////////////////////////////////////
>>> trait A[B[X, Y <: X, Z <: Y]]
>>>
>>> trait C[X, Y <: X, Z <: X]
>>> trait D[X, Y, Z <: X]
>>> trait E[X >: Y, Y, Z]
>>>
>>> type D1[X, Y <: X, Z <: Y] = D[X, Y, Z]
>>> type E1[X, Y <: X, Z <: Y] = E[X, Y, Z]
>>> ////////////////////////////////////////////////////////
>>>
>>> Now, the type applications A[D1], A[E1] are accepted. But I would like
>>> that it worked without aliases.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 6/16/09, Christos KK Loverdos <loverdos@...> wrote:
>>>
>>>> Hi,
>>>>
>>>> It is apparent that in the definitions of D, E, types Y & Z
>>>> respectively are unconstrained. This is incompatible with how A is
>>>> defined, where both Y & Z are constrained. So the errors you mention
>>>> (I have not run the example) are expected.
>>>>
>>>> BR
>>>> Christos
>>>>
>>>> On Jun 16, 2009, at 1:49 PM, Vladimir Reshetnikov wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> Given the following definitions,
>>>>>
>>>>> ///////////////////////////////////////////
>>>>> trait A[B[X, Y <: X, Z <: Y]]
>>>>>
>>>>> trait C[X, Y <: X, Z <: X]
>>>>> trait D[X, Y, Z <: X]
>>>>> trait E[X >: Y, Y, Z]
>>>>> ///////////////////////////////////////////
>>>>>
>>>>> Scala 2.7.5 accepts the type application A[C], but rejects A[D] and
>>>>> A[E]. But they all seem equally type-safe. What part of SLS describes
>>>>> how these type-checks should proceed? Is the current behavior correct
>>>>> or desirable?
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>
>>>> --
>>>>  __~O
>>>> -\ <,       Christos KK Loverdos
>>>> (*)/ (*)      http://ckkloverdos.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>>  __~O
>> -\ <,       Christos KK Loverdos
>> (*)/ (*)      http://ckkloverdos.com
>>
>>
>>
>>
>>
>>
>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>