Reified generics in Scala on .NET/CLR

Question

Scala (at least on the JVM) uses type erasure for Java compatibility. This feature is widely held to suck. Fixing this would be difficult on the JVM.

In contrast to the JVM situation, .NET supports reified generics. Does Scala's .NET implementation use them? If not, could it, or else what issues would using reification cause?

Answer 1

From the answer of this question, you can take that it might be not an advantage at all to have preserved generics in a VM, because it would still dictate what can be represented and what the relations between types are. (For more indepth, go to the original blog by Ola Bini).

Other examples:

• Comparing Impact of Type Erasure in Scala and Java (rather old, 2006) - blog post by Burak Emir, concluding

Erasure seems useful not just for backwards-compatibility, but because complete runtime-type information as promoted by dynamically typed languages comes at a cost. The design of the .NET CLR Generics tackles this cost by code specialization. The above cases should have made clear when it is erasure and when it is the language that is to be blamed for a particular shortcoming.

• Thoughts on erasure - mailing list thread. e.g. David Pollak:

The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system... Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime.

---

As far as I know Scala's .NET backend is far behind the current JVM implementation, and also doesn't support .NET's reified generics.

---

Scala 2.10 even goes further in the direction of abstracting type information from the actual virtual machine model. Martin Odersky presented the new reflection/reification interaction in a presentation which is for example embedded in this entry (beginning at 42'18").

I believe that you will then be able to use the type-tags (which replace manifests) to overcome the problems with pattern matching and erasure. There is a bit on this mailing list thread, but I don't know to what extent it works or doesn't.

(Pure speculation:) Going for more abstraction might help with backends for platforms which have even less type information than the JVM, e.g. a hypothetical compilation to JavaScript.

Answer 2

It's work in progress, carefully not to break Scala semantics between JVM and .NET.

I asked this question back in 2011 on the scala-tools mailinglist and the answer is given by Miguel Garcia in which he outlines the big picture:

Some quotes:

(1) What the Scala.Net preview currently does. As you have noticed, the erasure phase also runs as part of the pipeline. This is a "feature" of the preview version, a "feature" that had to be included because support for CLR Generics wasn't there yet (more on this below). There is however one big advantage to running JVM-style erasure in Scala.Net: all the Scala programs out there that rely on the Scala library can already be compiled on .Net, instead of waiting for CLR Generics to be ready. Those programs that rely on the Java JDK can also be compiled, subject to IKVM support of the JDK APIs in question [1].

(2) Support for CLR Generics in Scala.Net. The main motivation to support it is gaining interoperability with existing assemblies. In gaining that interoperability, care will be taken not to break away from Scala semantics. In other words, any valid Scala program is going to run and produce the same results on JVM and .NET. Which brings us to the work in progress [2]. The initial prototype handles only the C# subset of Scala. So now I'm addressing the rest. It's more work than initially anticipated but it's important to cover the whole language.

A few more comments regarding interop with .NET assemblies, in particular native issues. Yes, CLR assemblies can express using "native int" (different sizes on different CPUs), P/Invoke of C-functions exported by a .dll and such. Scala.Net does not aim to do that low-level trickery. The assembly interoperability of interest is at the level of "Common Language Specification", i.e. what one normally obtains from any C#, VB.NET, etc. compiler ("normally" i.e. unless using "[DllImport]" attributes and related C++-isms).

Quoting from the CLI spec:

--- start quote --- The Common Language Specification (CLS) -- The CLS is an agreement between language designers and framework (that is, class library) designers. It specifies a subset of the CTS (Common Type System) and a set of usage conventions. Languages provide their users the greatest ability to access frameworks by implementing at least those parts of the CTS that are part of the CLS. Similarly, frameworks will be most widely used if their publicly exported aspects (e.g., classes, interfaces, methods, and fields) use only types that are part of the CLS and that adhere to the CLS conventions. --- end quote ---

see for the whole thread:

https://groups.google.com/forum/?fromgroups#!topic/scala-tools/JDjstK1_uvM