I’m very pleased to announce that I’ve been invited to speak at the JAOO conference in Aarhus, Denmark, 28th September till 3rd October. I’ll speak on 1st October and I’ll actually be at the conference 29th September till 1st October attending sessions. The title of my presentation is “Learning F# and the Functional Point of View” and you can see the full abstract here. I’m very pleased to have been invited to speak at conference were the other speakers include Martin Fowler, Anders Hejlsberg, and Erik Meijer, and I’m really looking forward to it. Feel free to drop me a...

When asking the question how does functional programming help me with concurrent programming? The standard response tends to be functional programming use immutable data structures, read-only data structures can be shared between threads without issues, end of problem. Except it isn’t. Immutable data structures have a different set of problems associated with them when working on concurrent problems. This post will examine what these problems are, and then show that this is just a special case of a more general set of problems when working with immutable data structures. Finally will start taking a look at how we solve some...

I know I've been very quite here lately. The reason for this is I've spend a lot of time working on _the book_. Anyway, all thats nearly over now, so hopefully I can get back to being a bit more chatty. Anyway, here is the announcement that I've made just a few moments ago on the hubfs.net that says its almost finished printing: http://cs.hubfs.net/blogs/roberts_strange_f_blog/archive/2007/05/20/3153.aspx

Recently Don Syme made a post to the F# mailing list about some proposed changes to the F# libraries. In it talked about the virtues of using the new |> operator, sighting the following example as something it would be difficult without it:   let methods = System.AppDomain.CurrentDomain.GetAssemblies()             |> List.of_array |> List.map ( fun assm -> assm.GetTypes() ) |> Array.concat             |> List.of_array |> List.map ( fun t -> t.GetMethods() ) |> Array.concat   After squinting at it for a while I realised that I didn’t really understand what the sample was doing, let alone see the advantage...

Rico made some more interesting posts in his parser performance quiz, first producing a parser where the predicates are compiled into an in memory representation and also a parser where he produces IL on the fly. He talks about them here and here respectively.   So I ported both of these parsers to F#; as they demonstrate some nice uses of patterns commonly used in ML, such as take one data structure that is easy to read and transforming it into another than is easy to evaluate. This gives us 6 parsers in total, so...

Last night I too another look at my parser and unfortunately discovered some quite serious flaws in the algorithm, it was just too lazy and almost always terminated before it should. To fix these I basically ended up starting from scratch, I’ve reloaded the results. I’ll be tidying it up and talking about what went wrong as part of a wider comparison of all 3 parsers.

The snow is falling over Saint Germain en Laye and it makes everything look really pretty, but I have absolutely no whish to go outside, so I sit in the flat and what it fall and write this blog entry instead.   I’ve been following Rico Mariani’s performance quizzes for a while now and always found them interesting. The latest quiz on the performance of a parse, reminded me of a famous CS quote that every large software project has badly implement lisp engine in it. However I know little about lisp so I thought...

As noted here and here I have created some documents for F# using NDoc and the xml files that are available on with the F# download. There still in "beta" phase as I'll be making refinements such as search engine optimisations, as well as a build in search, but you may already find them useful. Enjoy!

This is an explanation of why the var “keyword” is like it is, and how this effects anonymous classes. I should probably point out I’m nothing to do with the C# design team, so these are merely my own opinions.   The var is all about type inference, it’s important to remember this is still static typing. The var keyword informs the compiler that it should try and infer the type of variable; if it can not do this a compile error is generated. One very important aspect of the var keyword is that it...

A couple of days ago Chris Sells made this post about the way best to parse command line augments. Given an xml document describing the structure of a command line augment, he wants to know would it be best to use code gen or an interpreter to parse command line arguments. Here is the xml structure he was talking about.   <args description="Two wrongs don't make a right, but three lefts do">  <arg name="lefts" description="Number of left turns" type="int" default=4" />  <arg name="attitude" description="Driver attitude" required="true" type="string" /></args>   F# (and the ML languages in general) offers a...