After you do the installation of the Visual Studio Shell, go to this site and download the latest version of F#, follow the simple installation instructions:

http://www.microsoft.com/downloads/details.aspx?FamilyID=61ad6924-93ad-48dc-8c67-60f7e7803d3c&displaylang=en

For instance, even with a normal “tupled” call, if you wrapped it with constants for the certain parameters, the same argument should hold. (Most overloaded functions in .NET are exactly this, in reverse order.) I guess the JIT could trace and when it sees a specific set of arguments being passed enough times, it can emit specific code for them or something like that…

I suppose the compiler could determine constants at compile time and make a decision to inline them.

In fact, just by poking around it seems as if the F# compiler already does this (statically) if you mark a function “inline”. For instance, create an inline wrapper around your polyval_aux and add cases for [] -> and a::b::c::[] -> a + b*x + c*x*x. Then disassemble the calling code and you’ll see it does statically handle the pattern matching.

It also seems to do it in other, simpler, cases, even without marking it inline. I guess over time the compiler will get better and do it on more cases? (Balancing of course, code bloat…)

For example, consider if I created a function by writing

let mypoly = polyval [1. 2. 3.];;

I think the way it’s handled now, the resulting “function” mypoly is really just essentially a delayed evaluation of polyval. If I call mypoly a million times with different arguments, polyval is still fully evaluated each time.

However, in theory I would think a smart enough CLR could recompile the original CIL code for polyval, with the constant list [1. 2. 3.] substituted in. A smart JIT compiler could then do some clever loop unrolling, essentially resulting in mypoly being compiled dynamically as if I’d written

let mypoly x = 1. + 2.*x + 3.*x*x;;

I think .NET’s CLR has just scratched the surface of the kind of runtime optimizations of which it’s ultimately capable, and I would think functional programming would be a paradigm where a JIT could do a lot of really interesting stuff. I predict that at some point, especially on many-core systems, .NET code will run faster than unmanaged C code.

Yes, the makeincrementor is utterly useless. I just wanted to illustrate the fact that you can have function factories that generate functions with runtime-decided parameters, so that I could then make the point that in the context of the CLR, one is essentially generating code on-the-fly. I don’t think the CLR actually takes advantage of this, but I’m intrigued by the unique possibilities of curried functions in a virtual machine environment.

On “currying”, Maybe it was just an example, but the definition of mmakeincrementor is actually useless. You could just as well do:
> let incrbyfive = (+) 5;;
val incrbyfive : (int -> int)
[I understand currying to be taking something of the form (a,b) -> c and turning into a -> b -> c. From there, we can do partial function application. Currying is more useful with .NET methods since they all come in "tupled" form.]

As far as OO, it quickly starts dropping out of your mindset. It’s so much easier to think and work with a function when you know it reacts only based on its arguments and not if someone somewhere else had called Foo on it before or not. On top of that, in a lot of places where someone would use inheritance, it’s quite easy just to pass in a function to “override” behaviour.

The real feat of F# is that MSRC/Don Syme got Microsoft to actually adopt it as a commercial endeavour. I’m guessing they had a “way in” due to the fact that they did generics for the CLR already.

First, I’d like to thank you for the article – in fact it’s the first time I have come across F# language.

This language will definitely be a good part of .NET familly – it will bring the functional paradigm to more people – just because Microsoft is the “father” of the language. It will bring the choice and it’s allways good, but to say the truth I prefer Haskell syntax – the readability is on much higher level.

PS: There is a mistake in the polyval_aux function example – the xpow value is not incremented correctly – it shouldn’t be (xpow *x), but (xpow + 1) …

I like Haskell syntax and F# syntax about the same, in fact. Actually, part of me likes Haskell a bit better, because it’s purer and simpler. F# is a bit of a mess and given that it’s owned by MS, it’s only going to get worse. But in the end, I think I’ll be able to do a lot more with F# than with Haskell, so I’m bothering to learn F#.

I don’t think the OO elements of F# are a crutch, they are an option. Sometimes functional approaches are best, sometimes imperitive and OO programming paradigms are called for. I imagine the best solution will often be a mix, such as an OO interface with a functional programming implementation behind the scenes. I don’t want my language to turn me into an idealogue, I want it to get out of the way and let *me* choose the approach.

At any rate, didn’t mean to insult Haskell programmers. It wasn’t about Haskell in particular but about the general arguments used in favor of functional languages. If Microsoft research had decided to implement Haskell as a .NET language and added OO features to it, I’d be writing this article about H#.

The only way the F# version would differ is to use explicit “match” declarations and lambda expressions because F# doesn’t have syntactic sugar for pattern-matching and “sections” that Haskell does.

Since they’re a fundamental language feature and a ubiquitous idiom, everyone who knows the language know what they mean. It might be a matter of taste which syntax you prefer, but I posit that you only prefer the F# versions because you’ve seen similar in other languages. I’m familiar with both versions and must say I prefer reading the less verbose syntax.

Apart from syntax, you could implement it some other way (less functionally, I guess) but your code wouldn’t be as good. The OO parts of F# are a nice crutch for beginners, but you can’t really run with crutches.