4 ms·

> What are the restrictions on F# that were posed by them? It does make it harder to add features to the language that do not map to the current reified "gener

> What are the restrictions on F# that were posed by them? It does make it harder to add features to the language that do not map to the current reified "generics" spec, for example higher-kinded polymorphic types. Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, or switch-on-type, for functional languages.

pron 7y ago
> Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, That's true (and will be addressed), but that's a problem that can be fixed by adding a feature, not removing a central one, which is why I said that both Java and .NET have made mistakes, and reified generics was one of .NET's. > or switch-on-type, for functional languages. There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. Perhaps you mean switching on A<Foo> and A<Bar>, where Foo and Bar are reference types (and possible with a subtype relationship between them), well even Haskell can't do that, and if there was a language that thought this is a good idea, it would be able to do it quite easily.
- willtim 7y ago
  > That's true (and will be addressed) Glad to hear it! It's probably the biggest issue trying to do functional programming on the JVM. > There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. The technique to implement ADTs in functional languages on the JVM has often been to add an integer tag to every subtype and switch on that, but it's ugly enough for interop that IIRC Scala doesn't do it (and is thus less efficient).
int_19h 7y ago
If such features can be implemented via runtime type erasure on JVM, you can still do that on CLR - it's not like it prohibits that technique, it just doesn't use it for generics. You can even have different languages agree on how they would implement it, so that they could fully interop. With modopt/modreq, you can capture it all in metadata, as well. It wouldn't interop with C# generics (although I don't see why it couldn't interop with C# by other, less convenient means). But if it can't be properly mapped to them when they're reified, why is there an expectation that it should? It seems to me like the gist of the argument here is that we can conflate two features into one, if only we remove all the conflicting bits of one of the features - which also happens to be the one much more broadly used at the moment. It's a strange trade-off.

pron 7y ago

> Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, That's true (and will be addressed), but that's a problem that can be fixed by adding a feature, not removing a central one, which is why I said that both Java and .NET have made mistakes, and reified generics was one of .NET's. > or switch-on-type, for functional languages. There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. Perhaps you mean switching on A<Foo> and A<Bar>, where Foo and Bar are reference types (and possible with a subtype relationship between them), well even Haskell can't do that, and if there was a language that thought this is a good idea, it would be able to do it quite easily.

willtim 7y ago
> That's true (and will be addressed) Glad to hear it! It's probably the biggest issue trying to do functional programming on the JVM. > There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes. The technique to implement ADTs in functional languages on the JVM has often been to add an integer tag to every subtype and switch on that, but it's ugly enough for interop that IIRC Scala doesn't do it (and is thus less efficient).

int_19h 7y ago

If such features can be implemented via runtime type erasure on JVM, you can still do that on CLR - it's not like it prohibits that technique, it just doesn't use it for generics. You can even have different languages agree on how they would implement it, so that they could fully interop. With modopt/modreq, you can capture it all in metadata, as well. It wouldn't interop with C# generics (although I don't see why it couldn't interop with C# by other, less convenient means). But if it can't be properly mapped to them when they're reified, why is there an expectation that it should? It seems to me like the gist of the argument here is that we can conflate two features into one, if only we remove all the conflicting bits of one of the features - which also happens to be the one much more broadly used at the moment. It's a strange trade-off.