I'm not sure type inference will work well by only allowing static optimizations outside the F# library.
If you look at the source code of the F# compiler there are many particular cases introduced in order to get simulated members working and inferred.
In your example calling toBytes with byte will not type check because byte doesn't have a ToBytes static member.
Anyway there seems to be a better way to implement type classes in .NET http://www.mlworkshop.org/2016-7.pdf?attredirects=0
7 votesplanned · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
Updating to planned to indicate this is approved in general terms. A detailed design and implementation would be needed.
Implementations of approved language design can now be submitted as pull requests to the appropriate branch of http://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for information on contributing to the F# language and core library.
Don Syme, F# Language and Core Library Evolution
For completeness it will be nice to allow to use the underscores in the declaration as well.
let func<_> = ()
Currently this is allowed: let func< 'T, .. > = ()
So, this should be allowed too: let func< .. > = ()
I like it. FSharpPlus had that feature longtime:(https://github.com/gmpl/FSharpPlus/blob/0f0550000077cb9da3f340612a84911e92c1a790/FSharpPlus/Extensions.fs#L49)
note that the GetSlice there support also negatives at the beginning of the string.
But now I see that in F#4.0 it doesn't work anymore since GetSlice was added in the F# core (without the negatives) and shadows the method in F#+ so if this feature is not accepted an option would be to avoid shadowing those functions further defined in Libraries.
This way everybody is free to decide to use negative indexing by using a library or writing an extension method.
I know you were not talking about FsControl (http://github.com/gmpl/FsControl) but in the post you mentioned (now moved to http://nut-cracker.azurewebsites.net/typeclasses-for-fsharp) I described a technique which inspired me later to develop FsControl, which runs in F# 3.0 so you don't need to use operators at all. Support for this technique (or similar) at the language level (not CLR) will be nice.
"...It's not extensible" It is extensible, just orphan instances are not supported.
"...you need to overload unused operators" this was due to a bug in F# parser, since the introduction of F# 3.0 this is not longer required.
Regarding the script issue, I really don't get it, could you possible open an issue in https://github.com/gmpl/FsControl/issues describing this problem?
I personally think F# can add Typeclass support requiring inline functions instead of support at the CLR Level. The same applies to Higher Kinds.
So the argument "this is a suggestion for the CLR team" is not valid, at least that's not what I'm suggesting.
To avoid the problem Don Syme mentions in the video, just keep ignoring extensions methods in overload resolution and create a "prelude" for existing types (that's the goal of FsControl).
136 votesGusty shared this idea ·