3 ms·

This seems inaccurate - generics aren't a problem for F# at all (the integration between the .NET and ML type systems is seamless here, as far as I'm aware). I

by kvb 13y ago

This seems inaccurate - generics aren't a problem for F# at all (the integration between the .NET and ML type systems is seamless here, as far as I'm aware). Indeed the people behind the .NET generics design (Don Syme and Andrew Kennedy in MSR) were coming from an ML background, and Don is the primary researcher behind F#. The big ML-.NET type system mismatches have to do with things like pervasive overloading in .NET making type inference difficult, nothing to do with reified generics.

bad_user 13y ago
Don Syme, Andrew Kennedy and many others that work for Microsoft are awesome. This doesn't make it any less of an appeal to authority that's not valid. The reality is that their creativity was limited by the constraints of .NET > The big ML-.NET type system mismatches have to do with things like pervasive overloading in .NET making type inference difficult, nothing to do with reified generics You've hinted at a side-effect, but no, it has to do with subtyping [1], which naturally leads to co/contra-variance [2]. Or to put it bluntly, in a nominal type system that has sub-typing, Hindley-Milner type-inference is not only "difficult" but actually impossible. And because F# had to be interoperable with .NET, then it needed C# generics. Pity, because there's many things that F# misses, like Ocaml functors, structural typing, type-classes, higher-kinded types and the list can continue. And I just love how List.sum<^T> is defined [3] (static member, FTW). [1] https://en.wikipedia.org/wiki/Subtyping https://en.wikipedia.org/wiki/Subtyping [2] https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 https://en.wikipedia.org/wiki/Covariance_and_contravariance_... [3] http://msdn.microsoft.com/en-us/library/ee353634.aspx http://msdn.microsoft.com/en-us/library/ee353634.aspx
- kvb 13y ago
  Sure, subtyping adds additional pain points (mostly separate from overloading, BTW). But I think this is mostly orthogonal to reified vs. erased generics. As it is, the .NET runtime supports reified generics and declaration-site variance (albeit limited to interfaces and delegates), and to my knowledge there's nothing stopping a different language/runtime from implementing reified generics even with usage-site variance (and Scala's type system only has declaration-site variance, anyway, AFAIK).
frowaway001 13y ago
Generics are "so seamless" in F# that they ship in fact with two versions of Generics.
- kvb 13y ago
  What does this even mean?
  - frowaway001 13y ago
    http://msdn.microsoft.com/en-us/library/dd233215.aspx http://msdn.microsoft.com/en-us/library/dd233215.aspx vs. http://msdn.microsoft.com/en-us/library/dd548046.aspx http://msdn.microsoft.com/en-us/library/dd548046.aspx
    - kvb 13y ago
      I wouldn't call that "two systems"; statically resolved type parameters are an extension of .NET generic parameters, not a separate system. In particular, a single definition can use both statically resolved and non-statically resolved parameters (e.g. in `let inline f x y = x + x`), and statically resolved type parameters can be used freely where normal .NET generic type parameters are expected (e.g. in `let inline g x = x + id x`). And these distinctions are fairly transparent to users in most cases anyway, since type inference is usually capable of inferring the kind of parameter needed. In any case, it is true that F#'s type systems has concepts that the CLR doesn't natively support, but I don't see how this demonstrates any weaknesses in the CLR or F#. The exact same thing is true of Scala on the JVM, as far as I can tell - how are erased generics an improvement?

by kvb 13y ago

bad_user 13y ago

Don Syme, Andrew Kennedy and many others that work for Microsoft are awesome. This doesn't make it any less of an appeal to authority that's not valid. The reality is that their creativity was limited by the constraints of .NET > The big ML-.NET type system mismatches have to do with things like pervasive overloading in .NET making type inference difficult, nothing to do with reified generics You've hinted at a side-effect, but no, it has to do with subtyping [1], which naturally leads to co/contra-variance [2]. Or to put it bluntly, in a nominal type system that has sub-typing, Hindley-Milner type-inference is not only "difficult" but actually impossible. And because F# had to be interoperable with .NET, then it needed C# generics. Pity, because there's many things that F# misses, like Ocaml functors, structural typing, type-classes, higher-kinded types and the list can continue. And I just love how List.sum<^T> is defined [3] (static member, FTW). [1] https://en.wikipedia.org/wiki/Subtyping https://en.wikipedia.org/wiki/Subtyping [2] https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 https://en.wikipedia.org/wiki/Covariance_and_contravariance_... [3] http://msdn.microsoft.com/en-us/library/ee353634.aspx http://msdn.microsoft.com/en-us/library/ee353634.aspx

kvb 13y ago
Sure, subtyping adds additional pain points (mostly separate from overloading, BTW). But I think this is mostly orthogonal to reified vs. erased generics. As it is, the .NET runtime supports reified generics and declaration-site variance (albeit limited to interfaces and delegates), and to my knowledge there's nothing stopping a different language/runtime from implementing reified generics even with usage-site variance (and Scala's type system only has declaration-site variance, anyway, AFAIK).

frowaway001 13y ago

Generics are "so seamless" in F# that they ship in fact with two versions of Generics.

kvb 13y ago
What does this even mean?
- frowaway001 13y ago
  http://msdn.microsoft.com/en-us/library/dd233215.aspx http://msdn.microsoft.com/en-us/library/dd233215.aspx vs. http://msdn.microsoft.com/en-us/library/dd548046.aspx http://msdn.microsoft.com/en-us/library/dd548046.aspx
  - kvb 13y ago
    I wouldn't call that "two systems"; statically resolved type parameters are an extension of .NET generic parameters, not a separate system. In particular, a single definition can use both statically resolved and non-statically resolved parameters (e.g. in `let inline f x y = x + x`), and statically resolved type parameters can be used freely where normal .NET generic type parameters are expected (e.g. in `let inline g x = x + id x`). And these distinctions are fairly transparent to users in most cases anyway, since type inference is usually capable of inferring the kind of parameter needed. In any case, it is true that F#'s type systems has concepts that the CLR doesn't natively support, but I don't see how this demonstrates any weaknesses in the CLR or F#. The exact same thing is true of Scala on the JVM, as far as I can tell - how are erased generics an improvement?