Inside Microsoft's New F# Language

robyn217 writes "There's a new language being formed in the bowels of Microsoft. Recently I got word that the language F# (pronounced F Sharp) is nearing workable stages at Microsoft Research. So, I went in for a look-see. What I found was an interesting blend of imperative (Java, C#) and functional languages(it's ML-based, too!). It looks pretty enticing to me from a computer science perspective, but I'm not sure it would fly in the professional market. I can see the ease of development that a language loosely based on ML would bring, but I can't see coders switching over in droves since it's a tough learning curve." Our previous story on F#.

Comments

It's OCaml for the .NET CLR...

[Anonymous Coward]

It's OCaml for the .NET CLR. Not a new language. Nothing to see here. Move along.

Re:It's OCaml for the .NET CLR...

[Junks Jerzey]

Yes, but the problem with most ML implementations is that they are academic toy languages. You can't do anything useful with them because you can't connect them to real I/O

In all honesty, what are you talking about? You can pick up OCaml right now and I/O is just fine. Period.

if you can you can't distribute the code as noone else has the environment

So everyone has to use C forever and ever?

Re:It's OCaml for the .NET CLR...

[MillionthMonkey]

(DISCLAIMER: I didn't write this myself- we were having an email conversation about F# today at work, and this is what our CEO had to say about it. I got his permission to repost his email here but he insisted on editing a few comments disparaging to Microsoft because he wants to encourage them to keep working on it.)
--snip--

F# seems to be based very closely upon ocaml, which was the language that I used for day to day work before Java.

I think ocaml is a fantastic language, although, like everything, it had a few significant problems five years ago:
- obscure [ F# could fix this ]
- not as many libraries as a mainstream language [ F# could fix this. ]
- not great module support - if module A depends on B, then B cannot depend on A.

Disclaimer: everything I say comes from personal, but old, experience, and a cursory look at the F# web site.

Interesting properties of ocaml:
1) Functions are first class objects. E.g..
let add x y = x+y;
let add3 = add 3;
print (add3 4);
-> 7
2) Polymorphism works well. So you could define a function that takes an array of objects x and a function that maps x to y, and produce an array of objects y. Eg
let a = [| 5,6,7 |] // an array of integers
print (Array.map add3 a)
-> [| 8,9,10 |]
3) Type checking is strong, compile time, and usually implicit. All types in the examples above are deduced correctly. Disadvantage: You can't have operator overloading, even for the plus sign... so + means integer addition, and +. means double addition.

4) You can return multiple values from a function
let cis t = (cos t,sin t);
let (ct,st) = cis (PI /. 2.0);
print ct;
-> 0.0

5) Variables are final by default, but can explicitly be made not-final. There are also control structures that make many things that one does in Java by changing variables simpler. This can make debugging simpler, but takes a while to get used to.

6) There is some very powerful pattern matching code - imagine a more powerful case where you could say

int x;
Point y
switch (x,y) {
case 7,null: do this
case 4,Point(3,?) : do that
case x,Point(y,x) : print y
default:
}

[ Actually, there is no direct concept of null, but that is not the point. ]

I particularly liked ocaml as it allowed imperative features, had GC and exceptions, and had a very good compiler that produced fast code. I was very impressed by the French academic group that made it and supported it.

[ Note examples are not valid ocaml - they are ocaml features with a javaified syntax to make them easier to explain, and besides, I have not used the language for years. ]

The current F# implementation does not sound very efficient for a variety of reasons. It is also not nicely polymorphic in the same way that ocaml is. This defeats a lot of the point of it. They need support for generics in the VM for these to work well. There is a different group at MS research working on this - I would be delighted if both the F# project and the generics project make it into the mainstream.

It is not clear how well the ML view of types will match up with the C# view of types. ML programming feels different to Java programming, and this could make the .NET library matching clumsy. But if they could make it work, then that could get rid of two of the biggest perceived issues that have prevented widespread adoption of ocaml.

--snip--

I like the idea

[Anonymous Coward]

My first year CS classes were taught in ML. It's a very potent language. I especially liked the type inference system. What other languages do in templates comes naturally in ML. Our CS prof gave us an example of Quicksort in 3 lines of readable code. As an academic language ML has problems interfacing with real life systems. OcaML was a step in the right direction and MS is building F# on it. I'll certainly try this one.

Haskell next?

[axxackall]

While I like ML (whole family) so much more than any imperative legacy (Java, C++, C, Perl), I see the main problem that any ML has with for modern RAD and with scripting is its static typing. And that's why I like (more than ML) Haskell - it's dynamically typed and thus it's much more appropriate both for operating scripting and for big app RAD.

Until today, both ML and Haskell had a common problem: a lack of commercial and real world interest in it and therefore a lack of real-world libraries and supporting frameworks. But now things are going to be changed.

First Ericson came with Erlang, an excelent essence of FP, LP, scripting and networking. Now M$ (I know - evil, but anyway) came with F# bringing OCaml to the real world saving from being forgotten somewhere in Inria.

What next? I think that would be Haskell, the language even more suprior to ML, with already OOP, Parallel and Cuncurrent extensions. Also I like its Functional-Logical dialect - Curry. But who will bring it to the real world? IBM?

Re:Haskell next?

[KieranElby]

I wouldn't bet against Microsoft bringing Haskell to the real world - their research department (which would put many universities to shame) has some top Haskell people, such as Simon Peyton Jones.
There's some interesting papers by him over here.

Re:Haskell next?

[milesegan]

Haskell is most certainly not dynamically typed. Like ML, it is a statically typed language with a compiler that does type inference at compile type. You don't usually have to manually declare types but you still have to get them right at compile time. There are some differences between ML's type system and Haskell's but they're basically the same animal.

ML and Haskell differ mainly in that ML is an eager language, which evaluates all arguments to functions before evaluating the function. Haskell is a lazy language which delays evalution of function arguments until their values are needed.

Erlang, on the other hand is dynamically typed.

Re:Funny quote of the day

[Eudoxe]

In France, students learn Caml during their first year before school of engineer. Maybe this will help the devel of ML in industry.

Re:This isn't all apparently...

[MisterFancypants]

OTOH, there is a right way and a wrong way of approaching this. In the example of DBC, MS would do good by providing an Eiffel implementation for their CLR. In the example of F#, MS would be more correct to introduce Scheme and LISP dialects rather than invent their own.

Bertrand Meyer is one of the biggest .NET boosters on the planet, and he already oversaw a port of Eiffel to .NET. This was available like a year ago.

There's also a Scheme compiler, called Hotdog, with a .NET backend:

Keep in mind that F# is but one of MANY language research projects going on at Microsoft Research, and there are many more going on at other sites that Microsoft is tangentially involved with.