New drafts of chapters from "Expert F#"


I’m very glad to announce the availability of drafts of Chapters 2-7 of Expert F#, of a book on F# which I’m currently in the process of co-authoring (thanks to James Huddleston at Apress for permission to post these).  This is one of two F# books planned for publication by Apress in 2007, the other being Foundations of F# by Robert Pickering, which I’m proudly helping to tech-review. Enjoy!


Chapter 2: Getting Started with F# and .NET


Chapter 3: Introducing Functional Programming


Chapter 4: Imperative Programming with F#


Chapter 5: Mastering Types and Generics (partial draft)


Chapter 6: Type Definitions, Classes and Objects


Chapter 7: Namespaces, Modules and Signatures (partial draft)


I’ve also posted two very preliminary documents which beginners may also find interesting, though the material should not be taken as absolutely authoritative.


Preliminary Code Formatting Guidelines


Preliminary Coding Convention Guidelines


I trust you will find this a useful resource for learning F# – it has been favourably received by people at MSR Cambridge. We’ll update the drafts for minor fixes, though of course the final version will be available in the book.  This is only a draft that has not undergone formal technical or copy editing, so please just ignore egregious mistakes and be patient with poor formatting and dangling symbolic cross-references (for various reasons Apress do not use Word cross-referencing and prefer to do it later in the production process).  Finally, some Word comments indicate where discrepancies exist with the current F# release.


 


 


 


 

Comments (17)

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

  2. Julien Laugel says:

    Many thanks for this pre-Xmas gift!

    Regards

  3. piggy says:

    Awesome! Thanks for this nice X’mas present.

  4. Don Syme’s WebLog on F# and Other Research Projects has three recent entries on F# which I would like

  5. lb says:

    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.

  6. dsyme says:

    Hi LB,

    please do send the comments along to my email, dsyme / AT / microsoft / DOT / com.

    don

  7. Mark E says:

    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.

  8. ian says:

    Is there a hint on the table of contents anywhere? I’d like to have a sense of the chapters-to-be.

  9. dsyme says:

    Here is the proposed TOC – let us know what you think!

    Cheers

    don

    Part I. The Language

    Chapter 1. Introduction

    Chapter 2. Getting Started with F# and .NET

    Chapter 3. Introducing Functional Programming

    Chapter 4. Imperative Programming

    Chapter 5. Mastering Types and Generics

    Chapter 6. Type Definitions, Classes, and Objects

    Chapter 7. Namespaces, Modules, and Signatures

    Chapter 8. Mastering F#:Common Techniques

    Chapter 9. Handling I/O

    Part II. Applied Topics

    Chapter 10. Windows Forms and Controls

    Chapter 11. Symbolic Manipulation

    Chapter 12. Graphics, Sound, and Text

    Chapter 13. Numerical Programming

    Chapter 14. Concurrent Programming

    Chapter 15. Web Programming

    Chapter 16. SQL and XML Processing

    Chapter 17.  Lexing and Parsing

    Chapter 18. Interoperating with C and COM

    Chapter 19. Testing F# Code

    Chapter 20. F# Coding Conventions

    Appendixes

    Appendix A. F# Syntax

    Appendix B. The F# Library

    Appendix C. F# in One Page

    Appendix D. Glossary

  10. falcon says:

    F# updates have slowed down recently…are we to expect a big, juicy, update soon?

  11. dsyme says:

    Hi falcon,

    A big new release is indeed coming soon: we’ll start blogging about it shortly.  We also took a bit of well-earned a break over Christmas!

    Cheers!

    don

  12. falcon says:

    By the way, chapter 10 refers to Windows forms…I hope you concentrate on WPF.  I also hope that you expand on "Imperative Reactive Programming," perhaps something like frtime, yampa, etc.  I hope you release rest of the book as draft chapters within the next couple of weeks so I can do a demo at work 😉

  13. moden says:

    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

  14. Tom Kirby-Green says:

    Hi Don,

    I’m really enjoying learning F# (and using what I learn on ‘downstream’ 😉 languages like C# 3 and C# 2) – is the book still on target re its publish date? Having enjoyed the 7 odd chapters you’ve kindly posted so far I look at the TOC and well… drool. Thanks for the awesome language.

    Kind regards,

    .tom

  15. 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!!!!!

  16. sjobak says:

    Ch3: Introducing Functional Programming

    In section ‘Defining Recursive Functions’ (right after the badFactorial example ;-)) I guess:

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

     and     odd  n = not(even(n-1))

    should be:

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

     and     odd  n = (n = 0) or not(even(n-1))

  17. C. Dunn says:

    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);