4 ms·

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 t

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.

sixbrx 13y ago
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-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.
bad_user 13y ago
> 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.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...

sixbrx 13y ago

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-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud... Apparently baking the generics into the generated bytecode has downsides in flexibility.

bad_user 13y ago

> 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.specialized http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...