« Return to Thread: [scala] Covariance in unsound
Re: [scala] Re: Covariance in unsound
by Matt Shannon
::
Rate this Message:
Hi Vladimir,
I'm not suggesting it is in any way satisfactory, but a lot of your
recent unsoundness examples can be fixed just by not using anonymous
classes. For example, if you instead write:
class B {
type X
var x : X = _
}
class C[+T] {
class D extends B { type X = T }
val s = new D
}
then the compiler complains appropriately. Some of your other examples
similarly get the correct result if you replace anonymous classes by
explicitly named ones.
Obviously this is not a fix. My suggestion is only that if you want to
learn more about the intricacies of the scala type system, and don't
want to wait until the bugs you highlighted are fixed, then you could
try using explicitly named classes in your investigations.
Matt
Adriaan Moors wrote:
> I was referring to the type that you refine /with./ { type X = T } is a
> structural type, and because of that, the overriding checks are different.
>
> adriaan
>
> On Sat, Jun 20, 2009 at 11:23 AM, Vladimir Reshetnikov
> <v.reshetnikov@... <mailto:v.reshetnikov@...>> wrote:
>
> Hi Adriaan,
>
> In my example the refinement is not structural - the overridden
> virtual type exists in the base class.
>
> Vladimir
>
> On 6/20/09, Adriaan Moors <adriaan.moors@...
> <mailto:adriaan.moors@...>> wrote:
> > Hi Vladimir,
> > Could you add this example to
> > https://lampsvn.epfl.ch/trac/scala/ticket/963, they
> > seem to be related. Override checks are too lax in structural
> refinements
> > --
> > your example doesn't type check when you simply write:
> >
> > scala> class C[+T] {
> > | type X = T
> > | }
> > <console>:5: error: covariant type T occurs in invariant position
> in type T
> > of type X
> > type X = T
> > ^
> >
> >
> > thanks!
> > adriaan
> >
> > On Sat, Jun 20, 2009 at 8:23 AM, Vladimir Reshetnikov <
> > v.reshetnikov@... <mailto:v.reshetnikov@...>> wrote:
> >
> >> Hi,
> >>
> >> It seems that the current implementation of covariance is unsound.
> >> Consider this code:
> >>
> >> ///////////////////////////////////////////////
> >> class B {
> >> type X
> >> var x : X = _
> >> }
> >> class C[+T] {
> >> val s = new B { type X = T }
> >> }
> >> ///////////////////////////////////////////////
> >>
> >> It compiles without errors in Scala
> 2.8.0.r18050-b20090618020144, but
> >> then we can write:
> >>
> >> scala> val c = new C[Int]
> >> c: C[Int] = C@1046270
> >>
> >> scala> val c1 = c : C[Any]
> >> c1: C[Any] = C@1046270
> >>
> >> scala> c1.s.x = ""
> >>
> >> scala> c.s.x
> >> java.lang.ClassCastException: java.lang.String cannot be cast to
> >> java.lang.Integer
> >> at scala.runtime.BoxesRunTime.unboxToInt(Unknown Source)
> >>
> >>
> >> I would like to read some papers on theoretical foundations of
> >> covariance in Scala. What would you recommend?
> >>
> >> Thanks,
> >> Vladimir
> >>
> >>
> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> >>
> >
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
I'm not suggesting it is in any way satisfactory, but a lot of your
recent unsoundness examples can be fixed just by not using anonymous
classes. For example, if you instead write:
class B {
type X
var x : X = _
}
class C[+T] {
class D extends B { type X = T }
val s = new D
}
then the compiler complains appropriately. Some of your other examples
similarly get the correct result if you replace anonymous classes by
explicitly named ones.
Obviously this is not a fix. My suggestion is only that if you want to
learn more about the intricacies of the scala type system, and don't
want to wait until the bugs you highlighted are fixed, then you could
try using explicitly named classes in your investigations.
Matt
Adriaan Moors wrote:
> I was referring to the type that you refine /with./ { type X = T } is a
> structural type, and because of that, the overriding checks are different.
>
> adriaan
>
> On Sat, Jun 20, 2009 at 11:23 AM, Vladimir Reshetnikov
> <v.reshetnikov@... <mailto:v.reshetnikov@...>> wrote:
>
> Hi Adriaan,
>
> In my example the refinement is not structural - the overridden
> virtual type exists in the base class.
>
> Vladimir
>
> On 6/20/09, Adriaan Moors <adriaan.moors@...
> <mailto:adriaan.moors@...>> wrote:
> > Hi Vladimir,
> > Could you add this example to
> > https://lampsvn.epfl.ch/trac/scala/ticket/963, they
> > seem to be related. Override checks are too lax in structural
> refinements
> > --
> > your example doesn't type check when you simply write:
> >
> > scala> class C[+T] {
> > | type X = T
> > | }
> > <console>:5: error: covariant type T occurs in invariant position
> in type T
> > of type X
> > type X = T
> > ^
> >
> >
> > thanks!
> > adriaan
> >
> > On Sat, Jun 20, 2009 at 8:23 AM, Vladimir Reshetnikov <
> > v.reshetnikov@... <mailto:v.reshetnikov@...>> wrote:
> >
> >> Hi,
> >>
> >> It seems that the current implementation of covariance is unsound.
> >> Consider this code:
> >>
> >> ///////////////////////////////////////////////
> >> class B {
> >> type X
> >> var x : X = _
> >> }
> >> class C[+T] {
> >> val s = new B { type X = T }
> >> }
> >> ///////////////////////////////////////////////
> >>
> >> It compiles without errors in Scala
> 2.8.0.r18050-b20090618020144, but
> >> then we can write:
> >>
> >> scala> val c = new C[Int]
> >> c: C[Int] = C@1046270
> >>
> >> scala> val c1 = c : C[Any]
> >> c1: C[Any] = C@1046270
> >>
> >> scala> c1.s.x = ""
> >>
> >> scala> c.s.x
> >> java.lang.ClassCastException: java.lang.String cannot be cast to
> >> java.lang.Integer
> >> at scala.runtime.BoxesRunTime.unboxToInt(Unknown Source)
> >>
> >>
> >> I would like to read some papers on theoretical foundations of
> >> covariance in Scala. What would you recommend?
> >>
> >> Thanks,
> >> Vladimir
> >>
> >>
> >> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> >>
> >
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
« Return to Thread: [scala] Covariance in unsound
| Free embeddable forum powered by Nabble | Forum Help |
