Add Higher Order Generics to F# (Type Classes)
Add ability to remove code duplication in F# by allowing to abstract over the container type 'M 'a.
Edmondo Pentangelo
shared this idea
Thank you for the feedback, but we are not currently planning to add this feature, in part because it would require significant changes to the CLR. In order to acheive the same effect, you could use an encoding like the one that Steffen suggested below. We don’t plan to add syntactic sugar for that encoding, however.
14 comments
-
Aaron Stainback commented
Can't you get pretty close with Inline?
http://fpish.net/topic/None/59208
http://code.google.com/p/fsharp-typeclasses/
https://gist.github.com/toyvo/1061780
http://www.nut-cracker.com.ar/index.php/typeclasses-for-fsharp
http://stackoverflow.com/questions/4034802/how-would-i-translate-a-haskell-type-class-into-fI think it's too bad this got declined, I would love to see it in the entire CLR but also even if it's just in F# only like erased type providers.
-
The Voice of Future Generation
commented
> The JVM has erasure-based generics, while .NET has reified generics (i.e., type arguments are available at runtime). That is why this suggestion would require changes to the CLR.
Why they just can't keep *-kinded generics reified,
and add (*->*)-kinded generics unreified with manifests or something?
MS ppl just cannot into PLs. -
Donna Malayeri (MSFT)
commented
The JVM has erasure-based generics, while .NET has reified generics (i.e., type arguments are available at runtime). That is why this suggestion would require changes to the CLR. In order to get around this issue, some JVM languages (such as Scala), pass around type manifests explicitly
-
Игорь Петров
commented
It was implemented, howewer, in languages such as Scala, Nice, CAL without any changes to JVM at all.
-
Steffen Forkmann commented
Hi,
since I don't believe the CLR team will provide support for type classes anytime soon. What do you think about giving some syntatic sugar for an implementation like this:
https://gist.github.com/1400378
Regards,
Steffen -
Rickasaurus
commented
-1 to Mixins/Traits, I'd really like our higher kinds to be something accessible outside of explicit class structures.
-
Don Syme
commented
Guys, as I said, this is really a suggestion for the .NET CLR team (see comment further below). Its good see it cross-posted there, but please make sure you redistribute your votes to other items.
-
Anonymous
commented
-
Ryan Riley
commented
+1 to Lewis Bruck's comment re: "mixins/traits ala Scala."
-
Lewis Bruck
commented
Instead of thinking of them as typeclasses or higher-kinded types which would require CLR changes, I think it would be almost as useful to support mixins/traits ala Scala. This would be a "walled garden" of extensibility/abstraction since the composition could only occur in F#; the final "mixed-in" class should be compilable to a normal .NET class for execution.
-
Frank Niemeyer
commented
I agree, higher-kinded types and type classes are two separate feature requests. (F* looks interesting.)
-
Rafael Reis
commented
Higher-order polymorphism is actually currently implemented in F*, an experimental extension of F# by Microsoft Research (http://research.microsoft.com/en-us/projects/fstar/).
I haven't played with it myself, however my guess is it's implementation is based on static resolution of type parameters. Although a "real", run-time implementation would be more desirable, its likelihood of implementation by the CLR is almost none whatsoever. F* provides, at least, a good basis for such work to be merged into the F# language.
Also, type classes are an orthogonal feature to higher-oder polymorphism - one which would be very attractive as well. Type classes would be useful without higher-order polymorphism as would be the other way around, but to a lesser degree. Hopefully, with F# abstract types one could make good use of it anyway.
-
J Cooper
commented
As much as I'm tempted to vote for this, I think Mr. Syme is correct--in any case this has nothing to do with Visual Studio as such.
-
Don Syme
commented
Note this is really a suggestion for the .NET CLR team - it would be hard to imagine doing this in F# without also doing it in the CLR. It would be great if you could put it under .NET and get people to vote on it there.
In general I strongly encourage F# users to add suggestions of the form "technology ABC should do XYZ to support F# better" to the _other_ categories for those technologies - those teams are then more likely to read those suggestions and understand the importance of improving support for F#.
