F# is a lovely language. I’m really glad it exists, and I love working with it. However, there is some room for improvement! I’ve gathered a list of all the things that I think are “missing” from F# today. A few of these I’ve found on UserVoice since I started compiling this list, and I’ll soon be adding the ones that aren’t there already. I’ll also update this post as I think of more.
1. Named Constraints
I have lots of constraints in my code, things like:
type Thing = abstract member Foo : int let foo<'a, 'b when 'a <: Thing and 'b : comparison> () = failwith "not implemented" let bar<'a, 'b when 'a <: Foo and 'b : comparison> () = failwith "not implemented"
Repeating those constraints over and over again is so not DRY. I wish I could define that constraint once and just reference it where needed.
Aside from the fact that C# and VB are getting compiler as a service, there’s the additional justification provided by F# quotations. When you have something as useful as F# quotations, why not provide a method to compile them to good quality code?
3. Type classes
F# doesn’t support type classes, which means that lots of useful things from Haskell don’t port easily. For instance, if you want to use map, you have to specify List.map, Seq.map, SomeOtherThing.map, etc., but with type classes, we could have a single “map” function that would find the right implementation depending on the (static) types it’s called on. There are workarounds, but they’re not the real thing. We need the real thing.
4. Parameterized Modules
One thing I tried to make my constraints DRY was to mention them at the module level:
type Thing = abstract member Foo : int module ThingMod<'a, 'b when 'a <: Thing and 'b : comparison> = let foo () = //code that mentions 'a or 'b failwith "not implemented" let bar () = //code that mentions 'a or 'b failwith "not implemented"
Of course this isn’t supported at all, but I can’t see a reason why it shouldn’t be.
For that matter, it’s a shame that the full ML module system isn’t supported. I really wish we could have either ML modules or type classes. Don’t need both, but do need one or the other.
5. Better syntax for anonymous functions
I know it’s traditional, but (fun x –> expr) is too clunky when C# is doing x => expr.
6. Macros, campl4 style or otherwise
Not having macros is limiting. You don’t need macro support often, but when you need it, you need it.
7. Better Intellisense
Intellisense for F# in VS 2012 is worlds better than in 2010, but it’s nowhere near as good as the C# support. Needs to work as well for F# as it does for C#.
This is required in today’s world. ReSharper, I’m looking at you, too.
9. Folder Creation in Solution Explorer
I can have folders in my F# project, I just can’t create them in Visual Studio. Disappointing. I can work around by editing the fsproj file, but I shouldn’t have to.
10. More F# Developers at Microsoft!
Come on, Microsoft! Your F# developers are doing great work, but you need more of them! It’s unacceptable that some Visual Studio features don’t work with F#, that things like Silverlight and Windows 8 get released with caveats like “F# is supported, but you have to use C# to build the front end.” Stop pretending this is a language that’s only useful for heavy computer science – it’s a general purpose language!