« Return to Thread: [scala] Conformance to bounds in higher-order type parameters

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

by Adriaan Moors-2 :: Rate this Message:

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

« Return to Thread: [scala] Conformance to bounds in higher-order type parameters