Runtime type info

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Runtime type info

Alan Lawrence
Hi,

I was wondering what the status was with regards to implementing  
runtime type tests? Specifically, I have a program:

object Test {
     class Foo {
         class Inner { }
         def acc(a : Any) = a.isInstanceOf[this.Inner];
         def make = new Inner;
     }

     def main(args : Array[String]) = {
         val f1=new Foo; val f2=new Foo;
         Console.println(""+f1.acc(f1.make) + " // " +f1.acc(f2.make));
     }
}

which at the moment prints out "true // true"

my belief is that this should print out "true // false", but that  
this feature hasn't been implemented yet (it used to be listed as a  
known issue on the Implementation Status page). I'm wondering what  
progress there has been on this?

If the answer's "not much", i.e. I'm not likely to be duplicating  
work, I'm wondering if this is something I can practically (help to)  
implement myself, and whether anyone could give me any pointers as to  
where I should be starting? (I'd say I have the source checked out  
and building, but...actually it doesn't seem to want to build...but  
that's another email!)

Cheers,
--Alan


---------
When you're up to your ears in alligators, it is difficult to  
remember that the reason you're there is to drain the swamp

Reply | Threaded
Open this post in threaded view
|

Re: Runtime type info

Martin Odersky
Hi Alan:
> I was wondering what the status was with regards to implementing  
> runtime type tests?
Runtime types are not supported. They have been dropped from the
"unimplemented features" list because the Scala spec no longer requires
them (in fact there is no "unimplemented features"  list anymore).

Michel Schinz has put quite a bit of work into them and describes the
results in his Ph.D. thesis. See

   http://library.epfl.ch/en/theses/?nr=3302

This work uncovered more problems that we anticipated. First, runtime
types for Scala do not go well together
with Java's very ad-hoc arrays. We had to either keep Java arrays and
accept a type hole or replace them with some wrapped structure and
accept the resulting problems of interoperability.

Second, runtime types were more costly than we thought. Their overhead
can range up to 100% of the running time of a program. There are some
known optimizations that we did not attempt to do for lack of time that
would reduce this overhead but we felt that it would still be
substantial. The problem here is that we had to duplicate all subtype
tests of the VM in the compiled code. The NextGen technique of
Cartwright can reduce this overhead by mapping each parameterized class
instance to a lightweight Java class. That way, one can re-use Java's
implementations of `instanceof' and type casts. Unfortunately,
Cartwright's technique is incompatible with contravariant type arguments
as they exist in Scala.

So the current status is that we are not actively working on run-time
types for Scala version 2. We might come back to it, if somebody has a
great new unexpected idea how to implement them, or if we become
convinced that they are
absolutely necessary for sound software development. If you want to give
it a try I would be very interested to follow this work. Just be
prepared that it won't be very easy. A good place to start would be
Michel's thesis (referred to above). Another good place is the very nice
work of Andrew Kennedy and Don Symes on generics in the .net CLR. They
had the advantage that they could change the VM, and made the best of
it, IMO.

In the meantime I'd like to explore to what degree GADT's might be a
substitute for run-time types. The nice thing about GADT's is that you
can implement type-safe conversions given an explicit descriptor of a
type. For instance, you can write type-safe marshalling/unmarshalling
that produce and take a sequence of bytes and a descriptor for a type T.
There are some limitations to this in what regards polymorphism. But it
might be possible to live with the limitations in the situations where
run-time types are most needed.

Yours

 -- Martin









> object Test {
>     class Foo {
>         class Inner { }
>         def acc(a : Any) = a.isInstanceOf[this.Inner];
>         def make = new Inner;
>     }
>
>     def main(args : Array[String]) = {
>         val f1=new Foo; val f2=new Foo;
>         Console.println(""+f1.acc(f1.make) + " // " +f1.acc(f2.make));
>     }
> }
>
> which at the moment prints out "true // true"
>
> my belief is that this should print out "true // false", but that  
> this feature hasn't been implemented yet (it used to be listed as a  
> known issue on the Implementation Status page). I'm wondering what  
> progress there has been on this?
>
> If the answer's "not much", i.e. I'm not likely to be duplicating  
> work, I'm wondering if this is something I can practically (help to)  
> implement myself, and whether anyone could give me any pointers as to  
> where I should be starting? (I'd say I have the source checked out  
> and building, but...actually it doesn't seem to want to build...but  
> that's another email!)
>
> Cheers,
> --Alan
>
>
> ---------
> When you're up to your ears in alligators, it is difficult to  
> remember that the reason you're there is to drain the swamp
>

Reply | Threaded
Open this post in threaded view
|

RE: Runtime type info

Judson, Ross
In reply to this post by Alan Lawrence
I don't think the public can see Michel's thesis, so I'm not able to
comment on his approach.  

Scala's type system obviously has quite a few complex features, which
makes reflection tougher.  But can we not divide the problem into two
parts -- introspection and testing?  I was looking at the UnPickler in
nsc, and it seems to me that adapting the UnPickler to extract the Scala
signature and lazily instantiate runtime types from scala.reflect
(instead of the compiler's types) might work quite well (apologies if
this was the approach taken -- I can't read Michel's work).  There is a
fairly close correspondence between the types the compiler uses and the
types in scala.reflect, so on first glance it looks possible at least.
We could also couple this to Java's Introspector (or to Java's own
reflection) to unify reflection over several models.  

This would gain us basic introspection across Scala types at runtime.

We could then look at various techniques for type testing.  

RJ
Reply | Threaded
Open this post in threaded view
|

Re: Runtime type info

Jakob Praher-2
Judson, Ross wrote:
> I don't think the public can see Michel's thesis, so I'm not able to
> comment on his approach.  

Stupid question: Is this phd viewable somewhere in the public? I would
be interested in reading it.

thanks
--Jakob

>
> Scala's type system obviously has quite a few complex features, which
> makes reflection tougher.  But can we not divide the problem into two
> parts -- introspection and testing?  I was looking at the UnPickler in
> nsc, and it seems to me that adapting the UnPickler to extract the Scala
> signature and lazily instantiate runtime types from scala.reflect
> (instead of the compiler's types) might work quite well (apologies if
> this was the approach taken -- I can't read Michel's work).  There is a
> fairly close correspondence between the types the compiler uses and the
> types in scala.reflect, so on first glance it looks possible at least.
> We could also couple this to Java's Introspector (or to Java's own
> reflection) to unify reflection over several models.  
>
> This would gain us basic introspection across Scala types at runtime.
>
> We could then look at various techniques for type testing.  
>
> RJ
>

Reply | Threaded
Open this post in threaded view
|

Re: Runtime type info

Michel Schinz
Jakob Praher <[hidden email]> writes:

> Stupid question: Is this phd viewable somewhere in the public? I would
> be interested in reading it.

I've put a copy at the following address:

http://lamp.epfl.ch/~schinz/thesis-final-A4.pdf

Notice that it describes the techniques used in the old Scala
compiler, so it's mostly of historical interest.

Michel.