I suggest you ...

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.

620 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Edmondo Pentangelo shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Patrick commented  ·   ·  Flag as inappropriate

        Type classes are so useful that I hope this decision will be reversed sometime in the future, as even a non-optimal implementation would be highly valuable in creating general purpose generic libraries. I believe that the lack of type classes is holding back the progress of F#, as it would largely makeup for the lack of functors. While having direct CLR support would be advantageous, surely a less efficient but still very useful type class implementation could be designed.

        While this proposal has currently been declined, largely for efficiency reasons, I'm still optimistic that the sheer usefulness and power of type classes will mean that a usable implementation will one day be added to F#.

      • psicollapse commented  ·   ·  Flag as inappropriate

        Type classes are the only thing keeping F# from being the best programming language ever created.

      • Aaron Stainback commented  ·   ·  Flag as inappropriate

        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-f

        I 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  ·   ·  Flag as inappropriate

        > 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  ·   ·  Flag as inappropriate

        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

      • Rickasaurus commented  ·   ·  Flag as inappropriate

        -1 to Mixins/Traits, I'd really like our higher kinds to be something accessible outside of explicit class structures.

      • Don Syme commented  ·   ·  Flag as inappropriate

        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.

      • Lewis Bruck commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        I agree, higher-kinded types and type classes are two separate feature requests. (F* looks interesting.)

      • Rafael Reis commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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#.

      Feedback and Knowledge Base