I am waiting for the runtime to be opened up. Although I know that is unlikely to happen. Opening up C# and F# are indeed interesting, but as far as engineering is concerned the real heavy lifting is done in the runtime. Unfortunately, as a Linux user the mono runtime has left me with a bad aftertaste. It is perhaps ok for C#, perhaps ok for use with unity, but for functional code that depends so heavily on proper handling of tail calls, mono is (well at least was) a mess and unstable. Further, developers in charge refused to concede that buggy/incorrect tail call behavior was a problem (why dont you just right loops). If anyone can report that this has changed I would be happy to give it another shot. I wont be able to thank all of you with a comment, but will certainly upvote.
True, a lot of the heavy lifting is done within the runtime. However Mono has been improving at a break-neck pace over the past few years - Mono 3.x with the new garbage-collector and LLVM backend can be quite efficient. Furthermore F# is bundled with Mono nowadays so hopefully they are aware of/fixing any issues with functional-style code, e.g. tail-calls.
I used Mono and F# for a project earlier this year and had no particular performance or behaviour issues, although my work was not generally performance-sensitive.
The latest Mono should be much better for handling F#, as it received some love from Xamarin, as they started promoting it. You can't blame Mono for not running F# well, when .NET itself had and probably still has its own share of problems: http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11...
I agree that even the CLR itself needs improvements for functional programming. Besides the tail calls link you gave, there is also (according to MS) inability to implement type classes because of CLR changes that would be necessary: https://visualstudio.uservoice.com/forums/121579-visual-stud...
I think F# would benefit a lot from either ML's module system or at least type classes as a simpler case. As it is it can only (directly) do single virtual dispatch (mainstream OO dispatch), which is pretty limiting and makes it more of a C# with different syntax.
F# could potentially get a module system in the future (a la OCaml or SML). I've put together some proof-of-concept code to show how modules could be implemented on top of the existing .NET type system, so at this point it's just a matter of refining that representation and then implementing that in the language/compiler.
I'd love to see some kind of typeclass support in F#...
In the meantime, honest question: what are modules in OCaml? I tried to read up on it online, but my understanding of the topic is still murky. Regular modules don't really seem that interesting (they look like modules and/or types/classes in F#), parametrized modules seem to be something that is missing in F#.
Second question, do you have that proof of concept code laying somewhere around? I'm just curious how it would look in F#...
Yes, F# is missing parameterized modules ("functors"); these are simply modules which are parameterized by other modules in the same way .NET generics (for example) allow you to parameterize one type by another type. The reason this would be nice to have in F# is that, while the CLR's generics are excellent in general, there are some things that can't be expressed using the CLR's type constraints. Supporting functors in F# would provide a nice way to work around this and allow you to write code which is more generic.
Here's my proof-of-concept code. I'll warn you now though -- it looks quite messy, because the goal was to show that functors could be supported on top of the existing .NET type system. If functors are ever added to the F# language, the syntax will be much, much cleaner.
This is great news (thank you for doing it)! Especially that it doesn't require changes within the CLR which seems to be a death sentence for proposals.
I've been teetering with trying F#, and a proper ML-like module system may tip the balance in its favor for me, I'm sure I'm not alone in that. It just didn't seem like a "real" ML without the module system or at least type classes.
That's a neat feature! So my aside about single dispatch was misplaced.
What I'm really after though is somewhat the opposite, which is static dispatch so that the functions called are known at compile time and can be optimized that way (I do a lot of numerics coding), so avoiding any method resolution lookup and even the vtable jumps and resulting target mispredicts. That's a nice feature of both type classes and ML's module system as usually implemented in functional languages. One really nice thing is they can also typically "dispatch" statically on return types of functions too which makes for some neat patterns as well using type inference.
Anyway thanks for pointing to that. It definitely beats the visitor pattern as is necessary in Java. And I assume it would work for more than two parameters too, which is another advantage over standard visitor.
