Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)


It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages.

Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.


> It's not like Scala has generics interop with Java

Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode.

> you can't use advanced Scala generics from Java

I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it?

> I'm sure they could have erased the extra stuff on CIL

Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics.

As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all).

> Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.

That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...


Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-stud...

Apparently baking the generics into the generated bytecode has downsides in flexibility.


Do you have any links on this? I had a quick duckduck but sadly nothing much came up.

My understanding of 'type erasure' is that it is a compiler step, that un-does all the generic information.

This means that you could just ignore CLR generics, interop not withstanding, to get it to run.

Why would this prevent anything been ported?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: