Given that the CLR generics implementation supports more features than the JVM's, such as reification, and the JVM's generics are a mere Java "compiler trick", why are higher-kinded types not possible in F# but possible in Scala? Does the CLR generics implementation somehow get in the way of things, whereas the JVM's lack of one allows you to go further than what the designers intended; somewhat like dynamic languages let you do tricks that a strongly-typed compiler would make impossible?
考虑到CLR泛型实现支持的特性比JVM的更多，比如具象化，而JVM的泛型只是Java的“编译器技巧”，为什么在f#中不可能有更高的类型，但在Scala中是可能的呢?CLR泛型实现在某种程度上阻碍了事情的发展，而JVM的缺乏使您可以更进一步，而不是设计者的意图;有点像动态语言，让您可以使用强类型编译器不可能实现的技巧?
2 个解决方案
#1
20
In principle, I'm not sure that there's anything preventing F# from including higher kinded types; the CLR doesn't natively support them, so a more indirect compilation strategy would need to be used, but that's the case for Scala on the JVM too. It may or may not be more complicated to do this on top of the CLR's reified generics, but I suspect the reason that F# doesn't include them is more philosophical. While higher kinded types would be nice, F#'s design tends to favor simple features that interoperate well with other .NET languages; higher kinded types would probably require significant effort to add to the language, would complicate type inference and other parts of the language and would definitely not interop well with C# and other .NET languages, so the costs (including opportunity costs) were probably perceived to outweigh the benefits.
原则上，我不确定是否有任何阻止f#的东西包括更高的kinded类型;CLR本身并不支持它们，因此需要使用一种更间接的编译策略，但JVM上的Scala也是如此。在CLR的具体化泛型中，这样做可能会更复杂，也可能不会更复杂，但我怀疑f#不包含它们的原因更具有哲学性。虽然较高的kinded类型会很好，但是f#的设计倾向于支持与其他。net语言互操作良好的简单特性;较高的kinded类型可能需要大量的努力来添加到语言中，这会使类型推断和语言的其他部分变得复杂，并且肯定不会与c#和其他。net语言兼容，因此，成本(包括机会成本)可能被认为超过了收益。
#2
-4
Better? Conceivably.
更好吗?可以想象。
The only difference I'm aware of is a feature of generics called "specialization." And it's available under programmer control in Scala. So... I'd have to say one can make the case that Scala is "better."
我所知道的唯一不同是泛型的一个特性，叫做“专门化”。它在Scala的程序员控制下是可用的。所以…我不得不说，我们可以证明Scala是“更好的”。
#1
20
In principle, I'm not sure that there's anything preventing F# from including higher kinded types; the CLR doesn't natively support them, so a more indirect compilation strategy would need to be used, but that's the case for Scala on the JVM too. It may or may not be more complicated to do this on top of the CLR's reified generics, but I suspect the reason that F# doesn't include them is more philosophical. While higher kinded types would be nice, F#'s design tends to favor simple features that interoperate well with other .NET languages; higher kinded types would probably require significant effort to add to the language, would complicate type inference and other parts of the language and would definitely not interop well with C# and other .NET languages, so the costs (including opportunity costs) were probably perceived to outweigh the benefits.
原则上，我不确定是否有任何阻止f#的东西包括更高的kinded类型;CLR本身并不支持它们，因此需要使用一种更间接的编译策略，但JVM上的Scala也是如此。在CLR的具体化泛型中，这样做可能会更复杂，也可能不会更复杂，但我怀疑f#不包含它们的原因更具有哲学性。虽然较高的kinded类型会很好，但是f#的设计倾向于支持与其他。net语言互操作良好的简单特性;较高的kinded类型可能需要大量的努力来添加到语言中，这会使类型推断和语言的其他部分变得复杂，并且肯定不会与c#和其他。net语言兼容，因此，成本(包括机会成本)可能被认为超过了收益。
#2
-4
Better? Conceivably.
更好吗?可以想象。
The only difference I'm aware of is a feature of generics called "specialization." And it's available under programmer control in Scala. So... I'd have to say one can make the case that Scala is "better."
我所知道的唯一不同是泛型的一个特性，叫做“专门化”。它在Scala的程序员控制下是可用的。所以…我不得不说，我们可以证明Scala是“更好的”。