Don Syme's WebLog on F# and Other Research Projects

[ Note: this post is now out-of-date: drafts of Chapters 2-7 are now available ] I'm very glad to announce

Awesome! Thanks for this nice X'mas present.

Good stuff Don.

One question: is it too late to provide feedback on these chapters?

While you ask us to "just ignore egregious mistakes " I, like a lot of programmers, just **love** offering criticism and generally pointing out flaws in the work of people who are much cleverer than myself.

Would it be inappropriate to email you (or someone) with feedback on paragraphs here or there?

Have a good xmas.

The chapters so far provide a good overview of the features available in F#, but I hope that later chapters delve more deeply into the issue of how to use these features to create a well-designed program with good 'compositionality'.

For example, chapter 6 really left me scratching my head.  There are so many different ways to construct types, and it's hard to understand why we need all these techniques, and why we'd want to sometimes choose one over another.

You can do most things with plain records, but not all.  So why have plain records?  You need discriminated unions to have the use of pattern matching, but then you're locked out of extensibility (unlike Scala's case classes which let you do pattern matching on extensible classes).  You need classes to do inheritance, and presumably to interact with .NET effectively.  The whole system seems like a bit of a mess, and it's hard to know how to take advantage of these different ways of constructing types.

So what do good F# programmers do (or are there none with enough experience yet to comment)?  Do they mostly avoid classes, only using them to interact with .NET?  Or rather, are records irrelevant to an experienced F# programmer, because classes can do everything a record can do and more?

If two programmers collaborate in F#, and each write their programs in a different style, one using discriminated unions, and the other using classes, are they able to effectively hook up their work later?  If one programmer makes a choice early on to use discriminated unions or records of functions in a manner that simulates objects, has he completely shot himself in the foot if later he finds himself needing to interact with .NET or wanting to use inheritance.  How hard is it to convert one style of code to another?

These are the questions I want answered by a book called "Expert F#".  I hope that later chapters will elucidate these points.

Right now, based on the first 7 chapters, F# comes across as solving the functional/OO debate by putting everything in one language... but not in a way where you can easily get the benefits of both styles.  It seems like you have to make a choice early on to structure your application a certain way, and then you end up missing out on half of what the languge has to offer.  I hope we will see in later chapters how these language features can be woven together successfully.

Chapter 4: Imperative Programming with F#

Page 14:

let sum n m =

   let mutable res = 0

   for i = n to m do

       res <- res + n /// Is it i instead of n?

   res

My URL is intranet so not available but I am creating a blog on learning this language (know all types of commercial languages so far only) because I find it beautiful and I can already see that features are flowing from this language (or functional languages) into other languages, not only C++, C# and VB.NET... Java is coming out with F3!!!!!

The poster is right: "even 1" would not terminate.  But it is clearer this way:

let rec even n = (n = 0) or not(not_odd(n-1))

and not_odd n = (n = 0) or not(even(n-1));

It's like Bill & Ted's Bogus Journey: not not not not excellent.

Here is another possibility:

let rec even n = (n = 0) || odd(n-1)

and    odd n = (n <> 0) && even(n-1);