Lambda the Ultimate

inactiveTopic Generics for the CLR
started 6/14/2001; 11:17:04 PM - last post 6/15/2001; 11:12:14 AM
Chris Rathman - Generics for the CLR  blueArrow
6/14/2001; 11:17:04 PM (reads: 1664, responses: 3)
Generics for the CLR
This is a proposal to implement parametric polymorphism in the .Net Common Language Runtime. The intriguing aspect is that the genericity is achieved via the Virtual Machine at run-time, rather than during compile cycle. To quote from the document:

Almost all previous implementation techniques for parametric polymorphism have assumed the traditional compile, link and run model of programming. Our implementation, on the other hand, takes advantage of the dynamic loading and code generation capabilities of the CLR. Its main features are as follows:

  1. "Just-in-time" type specialization. Instantiations of parameterized classes are loaded dynamically and the code for their methods is generated on demand.
  2. Code and representation sharing. Where possible, compiled code and data representations are shared between different instantiations.
  3. No boxing. Due to type specialization the implementation never needs to box values of primitive type.
  4. Efficient support of run-time types. The implementation makes use of a number of novel techniques to provide operations on run-time types that are efficient in the presence of code sharing and with minimal overhead for programs that make no use of them.

Posted to OOP by Chris Rathman on 6/14/01; 11:19:03 PM

Ehud Lamm - Re: Generics for the CLR  blueArrow
6/15/2001; 4:38:56 AM (reads: 875, responses: 0)
I have to read the report, but isn't the whole point of generics (or at least an important part of it) to do this during compile time? It seem like this is even worse that runtime dispatching: we are talking code generation at run time?! Seems a bit strange.

Daniel Dittmar - Re: Generics for the CLR  blueArrow
6/15/2001; 9:17:10 AM (reads: 880, responses: 1)
If you consider Java class files (don't know much about .Net formats), class files for Vector<String> and for Vector<StringBuffer> will differ only in the method signatures. So instead of making all those similar files part of the .jar, one could use a special class loader which creates these files on demand.

So there is overhead only when the class gets loaded.

Ehud Lamm - Re: Generics for the CLR  blueArrow
6/15/2001; 11:12:14 AM (reads: 939, responses: 0)
It is a bit more than that since type information is kept during run time (as explained in the paper).