Scala.NET(jdk2ikvm.jar/scalacompiler.exe): Why is there type erasure when compiling to dotnet?

Scala is a uniform language, it should behave the same on any platform it runs, so if erasure was embraced due to java or to whatever reason, then erasure will apply in any environment it runs despite the later having more capabilities.

If you need type information, use manifests.

On Sun, Sep 18, 2011 at 7:29 PM, Dave <dave.mahabiersing@hotmail.com> wrote:

When I compile a scala source to dotnet I get warnings for type
erasure for the lines with the type parameters I hoped for they would
be reified in a polymorphic way. When I run the executable it crashes
just like in jvm.
System.InvalidCastException: impl.Lit cannot be cast to
extension.EvalExp

Is this a bug or not yet implemented?

C:\scala-2.9.1.final\examples\hybridsolutionexpressionproblem
\dotnet>scalac -Xpl
ugin C:/scala-2.9.1.final/plugins/jdk2ikvm.jar -P:jdk2ikvm:output-
directory:. -d
 . -Ystop-after:superaccessors -Yrangepos src/expressionproblem.scala -
sourcepat
h src -unchecked
src\expressionproblem.scala:14: warning: abstract type V in type V is
unchecked
since it is eliminated by erasure
           if (v.isInstanceOf[V]) accept(v.asInstanceOf[V])
                             ^
src\expressionproblem.scala:22: warning: abstract type E in type E is
unchecked
since it is eliminated by erasure
           if (e.isInstanceOf[E]) call(e.asInstanceOf[E])
                             ^
[jdk2ikvm] time to prepare output:  0 min,  0 sec
[jdk2ikvm] time to serialize:       0 min,  0 sec
[jdk2ikvm] wall-clock time:         0 min,  0 sec
two warnings found

C:\scala-2.9.1.final\examples\hybridsolutionexpressionproblem
\dotnet>scalacompil
er -Ydebug -d . -target:msil -Ystruct-dispatch:no-cache -no-
specialization -Xass
em-name expressionproblem -Xassem-extdirs C:/scala-2.9.1.final/bin -
Xshow-class
main.Main expressionproblem.scala -sourcepath . -unchecked
[running phase parser on expressionproblem.scala]
[running phase namer on expressionproblem.scala]
[running phase packageobjects on expressionproblem.scala]
[running phase typer on expressionproblem.scala]
expressionproblem.scala:14: warning: abstract type V in type V is
unchecked sinc
e it is eliminated by erasure
           if (v.isInstanceOf[V]) accept(v.asInstanceOf[V])
                             ^
expressionproblem.scala:22: warning: abstract type E in type E is
unchecked sinc
e it is eliminated by erasure
           if (e.isInstanceOf[E]) call(e.asInstanceOf[E])
                             ^
[running phase superaccessors on expressionproblem.scala]
[running phase pickler on expressionproblem.scala]
[running phase refchecks on expressionproblem.scala]
[running phase uncurry on expressionproblem.scala]
[running phase tailcalls on expressionproblem.scala]
[running phase specialize on expressionproblem.scala]
[running phase explicitouter on expressionproblem.scala]
[running phase erasure on expressionproblem.scala]
[running phase lazyvals on expressionproblem.scala]
[running phase lambdalift on expressionproblem.scala]
[running phase constructors on expressionproblem.scala]
[running phase mixin on expressionproblem.scala]
[running phase cleanup on expressionproblem.scala]
[running phase icode on expressionproblem.scala]
[running phase inliner on expressionproblem.scala]
[running phase closelim on expressionproblem.scala]
[running phase dce on expressionproblem.scala]
[running phase msil on icode]
two warnings found

Dave, 
I guess there are two aspects to your question: 
(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. 

Miguel http://lamp.epfl.ch/~magarcia/ScalaNET/
[1] http://www.ikvm.net/ 
[2] http://lamp.epfl.ch/~magarcia/ScalaNET/slides/2011-09-06-GenericsGettingCloser.pdf 

Thanks for clearing this up.
I had the false assumption that Scala.NET would compile to full native
dotnet that is similar to C#.NET, F#.NET, Visual Basic.NET and
interop with them, but it is a subset of dotnet that still has to be
interoperable with jvm to clr ikvm compiled binaries.

But then it is not guaranteed to interop with native .NET compiled
binaries which I think many will assume.

On 19 sep, 18:15, Miguel Garcia wrote:
> Dave,
>
> I guess there are two aspects to your question:
>
> (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.
>
> Miguelhttp://lamp.epfl.ch/~magarcia/ScalaNET/
>
> [1]http://www.ikvm.net/
>
> [2]http://lamp.epfl.ch/~magarcia/ScalaNET/slides/2011-09-06-GenericsGett...

Dave, 
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 designersand 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 byimplementing at least those parts of the CTS that are part of the CLS. Similarly, frameworks willbe most widely used if their publicly exported aspects (e.g., classes, interfaces, methods, andfields) use only types that are part of the CLS and that adhere to the CLS conventions.--- end quote ---

Miguel http://lamp.epfl.ch/~magarcia/ScalaNET/

So C# and VB should use the CLSCompliantAttribute in their assemblies
if they want a guarantee to interop with Scala.NET

C#.NET [assembly: CLSCompliant(true)]
VB.NET

And reified generics is only a language feature of C#
But does the CLSCompliantAttribute turn off reified generics in C# as
well?

On 19 sep, 19:54, Miguel Garcia wrote:
> Dave,
>
> 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:
>

Dave, 
C# 4.0 generics are mapped as-is to CLR generics. In fact, as of C# 3.0 the CLR capabilities even surpassed what C# supported (regarding variance). Therefore, there's no compiler switch that affects that mapping. For Scala.Net, we'll also use CLR generics, while keeping things like Manifests that, granted, are "compiler magic" and somewhat overlapping with CLR Generics. Why keep them? Because they work out of the box right now, and so as to allow hassle-free recompilation of Scala programs developed on JVM with Scala.Net. 
Miguel http://lamp.epfl.ch/~magarcia/ScalaNET/