Planet F#

Fun with Functional - Currying di C#

Sat, 28 Nov 2009 21:48:00 GMT

Apa itu Currying?

Currying adalah sebuah teknik yang sangat lazim dipakai di bahasa pemrograman fungsional, seperti Haskell, LISP, OCaml, JavaScript, dan tentu saja, F#. Bagi yang belum memahami apa itu currying, lihatlah contoh program F# di bawah:

let add x y = x + y

printf "%d" (add 5 2) // should print 7

Code di atas adalah deklarasi sebuah fungsi add. Tipe dari add adalah int -> int -> int. Bagi anda yang terbiasa memakai delegate System.Func maupun System.Action, tipe data add ini apabila ditulis dengan sintaksis C# menggunakan Func adalah Func<int, int, int>. Kedua buah int pertama adalah tipe parameter, dan int yang terakhir adalah function’s return type.

Nah, C# adalah sebuah bahasa yang belum full functional programming seperti halnya F#, sehingga di F# kita dapat menuliskan bentuk seperti ini:

let addFiveWith = add 5

printf "%d" (addFiveWith 2) // should print 7

Tipe dari addFiveWith adalah int -> int, yaitu fungsi add yang tadinya memiliki dua buah parameter, menjadi tinggal satu, karena parameter pertama diganti dengan lima. Inilah yang disebut dengan currying, mendapatkan fungsi baru (addFiveWith) dengan memberi sebagian parameter pada fungsi awal (add).

Salah satu cara pandang tentang apa itu currying adalah dengan memahami notasi dari tipe fungsi add. Ingat, notasi dari tipe add adalah:

int -> int -> int

Secara C#, hal tersebut ditulis sebagai:

Func<int, int, int>

Anda harus memahami bahwa keduanya walaupun sepintas sama, sebenarnya berbeda. Pada C#, int yang terakhir selalu return type, artinya terdapat perbedaan yang jelas mana yang parameter dan mana yang return type. Nah, tipe add di dalam F# berbeda, tidak ada perbedaan yang jelas yang mana parameter dan mana yang return type, sehingga anda bebas menginterpretasikan tipe add sebagai:

(int -> int) -> (int) // fungsi dengan dua buah parameter int dan return type sebuah int

(int) -> (int -> int) // fungsi dengan sebuah parameter int dan return type sebuah fungsi berparameter int dan return type int

Pada saat anda memanggil add 5 2, maka return type adalah penjumlahan dari keduanya yaitu 7.
Pada saat anda memanggil add 5, maka return type adalah sebuah fungsi yang berparameter int dan return type int yang bernilai parameter pertamanya ditambahkan dengan 5. Karena perbedaan inilah, maka lambda expression C# dan F# itu berbeda, seperti yang akan kita lihat nanti bagaimana cara mengonversinya.

Apabila anda heran dari bahasa mana kata currying berasal, maka currying itu adalah nama seorang matematikawan Haskell Curry. Ya, bahasa Haskell yang kesohor adalah juga berasal dari namanya. Yang berjasa dalam menemukan currying sebenarnya bukan cuma Haskell Curry, tapi juga seorang bernama Moses Schönfinkel. Beberapa orang ada yang menyarankan untuk mengganti currying dengan Schönfinkelisation. Tanpa merendahkan Mas Moses, kita harus bersyukur bahwa nama yang terakhir tidak dipakai, mengingat kemungkinan terjadinya kesalahan ketik yang besar.

Salah Satu Contoh, Currying Could be Useful

Mari kita kembali ke masa kuliah dan mengambil analisis numerik, menghitung turunan secara numerik. Masih ingat apa itu turunan? Disebut sebagai perubahan sesaat dari sebuah fungsi, jadi kita bisa mendapatkan kemiringan (gradien) fungsi pada titik tertentu, dan bukan pada interval tertentu apabila turunan tidak digunakan. Pertama kali ditemukan oleh Sir Isaac Newton pada saat kuliah di Cambridge untuk memodelkan 3 hukum Newton. Saat itu Pak Ishak (sapaan akrab Newton) ingin merumuskan kecepatan sesaat maupun percepatan sesaat.

Definisi asal turunan adalah:

Terlihat jelas dari persamaan di atas bahwa kemiringan sesaat dapat ditemukan dengan membuat Δx sekecil mungkin, karena apabila Δx besar, maka persamaan di atas adalah definisi untuk mendapatkan kemiringan rata-rata, dan bukan sesaat. Untuk mengaproksimasi persamaan tersebut secara numerik, biasanya digunakan rumus:

Sip, mari kita tulis dalam bentuk F#:

let derivative f x =
    let dx = sqrt epsilon_float
    (f(x + dx) - f(x - dx)) / (2.0 * dx)

Agar persamaan di atas benar mengaproksimasi turunan, maka dx harus dibuat sekecil mungkin. Berhati-hati dengan bilangan floating point karena anda tidak dapat begitu saja memberikan sembarang nilai kecil. Beberapa nilai kecil floating point, apabila anda tambahkan dengan satu, hasilnya adalah satu (yang seharusnya satu koma sekian). Cara untuk mendapatkan bilangan kecil yang mana apabila ditambahkan dengan satu hasilnya bukan satu adalah seperti yang terlihat di atas. Konstanta epsilon_float didefinisikan di FSharp.PowerPack.dll. Tentu saja, anda bebas untuk mengganti nilai ini dengan 0.00005 atau terserah anda.

Sebelum kita analisa tipe dari derivative, mari kita lihat bagaimana cara menggunakannya:

let result = derivative (fun x -> x ** 2.0) 3.0

printfn "%f" result // should print 6.0

Tujuan dari fungsi tersebut adalah untuk menghitung turunan dari fungsi x kuadrat pada saat x bernilai 3. Seperti kita tahu, fungsi x^2 turunannya adalah 2.x, dan pada saat x bernilai 3, maka nilainya adalah 2 . 3 = 6. Parameter pertama pada pemanggilan derivative adalah sintaksis lambda expression di F#, yang apabila di C# kira-kira x => x ** 2.0 (tidak ada operator ** di C#, cuma pengandaian).

Tipe dari derivative adalah:

(float -> float) -> float -> float

Sebelum menganalisa lebih jauh, anda harus ingat bahwa float di F# berarti System.Double. Parameter pertama adalah sebuah fungsi dengan sebuah parameter float dan return type float. Pada contoh pemanggilan di atas, parameter ini bernilai (fun x -> x ** 2.0), diikuti oleh parameter kedua adalah float, anda suplai dengan nilai 3.0, yaitu anda ingin menghitung turunan dari x^2 di x = 3. Tentu saja, float yang terakhir adalah return type dari fungsi derivative, bernilai 6 apabila dua parameter adalah sesuai dengan yang di atas.

Salah satu kelebihan F# adalah type inference is ubiquitous. F# compiler dan interpreter dapat mengenali tipe data di atas tanpa anda menulis secara eksplisit tipe dari f dan x. Lebih ekstrim lagi, apabila anda memanggil printfn "%d" result (bukan "%f" untuk menampilkan float) , anda akan mendapatkan compile-time-error dan bukan runtime-error. Artinya compiler dan interpreter F# mengecek sampai ke parameter format string, sesuatu yang biasanya dilakukan pada saat runtime.

Nah, masih ingat dengan currying? Sepintas fungsi derivative cuma menghasilkan sebuah nilai float. Dengan menggunakan currying, anda bisa mendapatkan fungsi turunan seperti di bawah:

let f x = x ** 3.0 + 3.0 * x
let f' = derivative f // f' adalah turunan dari x^3 + 3x -> 3x^2 + 3
printfn "%f" (f' 2.0) // 3.2.2 + 3 = 15

Simple eh? Anda baru saja melihat salah kehebatan dari currying, kalau pada code di atas pemanggilannya adalah derivative f 2.0, anda akan mendapat sebuah nilai 15.0, namun kalau anda memanggilnya derivative f, anda akan mendapatkan sebuah fungsi turunan dari f. Jadi dengan currying, anda hanya membuat sebuah fungsi, return type bisa banyak, tergantung bagaimana parameternya. Biar lebih seru, mari kita membuat sebuah fungsi untuk menampilkan grafik dari fungsi dengan memanfaatkan komponen XYGraph yang dapat anda cari di internet.

let Plot (from:float) (step:float) (final:float) (func:float -> float) =
    let form = new Form(Visible = true, TopMost = true)
    form.KeyPress.AddHandler (fun _ _ -> form.Close())
    let graph = new XYGraph(Dock = DockStyle.Fill)
    graph.XtraTitle <- String.Empty
    graph.XtraLabelX <- String.Empty
    graph.XtraLabelY <- String.Empty
    form.Controls.Add(graph)
    let g = graph.AddGraph(String.Empty, Drawing2D.DashStyle.Solid, Color.Red, 1, false)
    for x in from .. step .. final do
        graph.AddValue(g, float32 x, float32 (func x))
    graph.DrawAll() let f x = x ** 3.0 + 3.0 * x

let f' = derivative f // f' adalah turunan dari x^3 + 3x -> 3x^2 + 3
Plot -3.0 0.05 3.0 f
Plot -3.0 0.05 3.0 f'

Berikut adalah tampilan dari program di atas:

Gambar kiri adalah fungsi f(x) = (x^3 + 3x) dan gambar kanan adalah fungsi f’(x) = (3x^2 + 3).

Enough Talking About F#, I’m a C# Folks!

Ternyata masih tidak ingin beralih ke F# rupanya. Oke, kalau begitu mari kita bahas bagaimana currying juga bisa dilakukan di C#. Pertama, perhatikan sebuah fungsi sederhana berikut:

public static int Add(int number1, int number2)
{
return number1 + number2;
}

Nah, untuk mendapatkan fungsi AddFiveWith seperti yang telah kita lakukan di awal, kira-kira code-nya adalah seperti ini:

Func<int, int, int> addDelegate = Add;
var addFiveWith = addDelegate.Curry(5);
Console.WriteLine(addFiveWith(7)); // akan mencetak 12

Sekarang, mari kita analisa bersama, bagaimana kira-kira mengimplementasi fungsi Curry. Input dari fungsi ini adalah sebuah fungsi dengan jumlah parameter dua, disusul dengan sebuah parameter yang akan menggantikan parameter pertama dengan sebuah nilai dari user (5 untuk kasus di atas). Tipe data kembalian adalah sebuah fungsi dengan sebuah parameter, dan tipe kembalian dari fungsi ini adalah sama dengan fungsi asal. Untuk lebih jelasnya perhatikan code di bawah:

public static TipeFungsiKembalian Curry<TypeList>(this TipeFungsiAsal fungsi, TipeParameter1FungsiAsal param1)
{
// bla bla bla
}

Untuk mendapatkan TypeList, pertama mari kita menganalisa TipeFungsiAsal. TipeFungsiAsal adalah fungsi dengan parameter dua, masing-masing parameter boleh bertipe berbeda, dan return type dari fungsi ini boleh berbeda dari kedua parameternya. Maka kita dapat menulis TipeFungsiAsal sebagai:

Func<T1, T2, TResult>

Dengan mudahnya, tipe TipeParameter1FungsiAsal adalah T1.

Terakhir TipeFungsiKembalian adalah sebuah fungsi dengan sebuah parameter yang mana tipe dari parameter ini adalah sama dengan tipe dari parameter ke dua dari fungsi asal, dan return type adalah sama dengan return type dari fungsi asal. Maka, tipenya adalah:

Func<T2, TResult>

Berarti, TypeList dapat kita tulis sebagai, T1, T2, TResult sehingga fungsi Curry signaturenya adalah:

public static Func<T2, TResult> Curry<T1, T2, TResult>(this Func<T1, T2, TResult> func, T1 param1)
{
// bla bla bla
}

Terakhir, mari kita ganti “bla bla bla” dengan sesuatu yang dimengerti oleh C# compiler. Tipe kembalian adalah Func<T2, TResult>, yang diubah ke lambda expression menjadi:

p2 => func(param1, p2);

Harus diingat bahwa tipe kembalian dari func adalah TResult, sehingga lambda expression di atas bertipe Func<T2, TResult>. Dengan type inference, C# compiler cukup pintar untuk mengetahui bahwa tipe p2 adalah T2. Sekarang, fungsi Curry dapat kita implementasi dalam versi lengkap:

public static Func<T2, TResult> Curry<T1, T2, TResult>(this Func<T1, T2, TResult> func, T1 param1)
{
return p2 => func(param1, p2);
}

Sederhana bukan? Mari kita lihat salah satu contoh penggunaan:

public static double Derivative(Func<double, double> f, double x)
{
    double dx = 2.220446049e-8;
    return (f(x + dx) - f(x - dx)) / (2*dx);
}

Func<Func<double, double>, double, double> diff = Derivative;
Func<double, double> xSquare = x => Math.Pow(x, 2);

var twoX = diff.Curry(xSquare); // mendapatkan turunan dari x kuadrat, yaitu 2 * x
Console.WriteLine(twoX(2)); // 4
Console.WriteLine(twoX(3)); // 6
Console.WriteLine(twoX(4)); // 8

Contoh penggunaan lain yang lebih sederhana:

public static string NamaDanUsia(string nama, int usia)
{
return string.Format("Halo, nama saya {0} berusia {1}", nama, usia);
}

Func<string, int, string> namaUsiaDelegate = NamaDanUsia;
var budiDenganUsia = namaUsiaDelegate.Curry("Budi");
Console.WriteLine(budiDenganUsia(3)); // Halo, nama saya Budi berusia 3
Console.WriteLine(budiDenganUsia(10)); // Halo, nama saya Budi berusia 10

Console.WriteLine(budiDenganUsia(20)); // Halo, nama saya Budi berusia 20

Tentu saja, fungsi Curry yang kita buat hanya berlaku untuk fungsi dengan return type non-void (untuk yang void silakan implementasikan sendiri, dengan memanfaatkan System.Action), dan dengan dua buah parameter. Untuk tiga parameter dan selebihnya, masing-masing dibuat Curry-nya:

public static Func<T2, T3, TResult> Curry<T1, T2, T3, TResult>(this Func<T1, T2, T3, TResult> func, T1 param1)
{
    return (p2, p3) => func(param1, p2, p3);
}

Func<T2, T3, T4, TResult> Curry<T1, T2, T3, T4, TResult>(this Func<T1, T2, T3, T4, TResult> func, T1 param1)
{
    return (p2, p3, p4) => func(param1, p2, p3, p4);
}

public static int AddNumbers(int n1, int n2, int n3, int n4)
{
    return n1 + n2 + n3 + n4;
}

Func<int, int, int, int, int> addNumbersDelegate = AddNumbers;
var addFiveWith = addNumbersDelegate.Curry(5);
var addFiveAndTwoWith = addNumbersDelegate.Curry(5).Curry(2);
var ten = addNumbersDelegate.Curry(1).Curry(2).Curry(3)(4); // sintaks bodoh tapi bergaya pengganti addNumbersDelegate(1, 2, 3, 4)
addFiveWith(3, 2, 1); // 11
addFiveAndTwoWith(1, 2); // 10

Setelah anda paham garis besarnya, silakan buat function overload-nya agar pemanggilan Curry tidak dilakukan berkali-kali seperti pada contoh di atas, contoh:

// Curry dua parameter sekaligus
Func<T2, T3, T4, TResult> Curry<T1, T2, T3, T4, TResult>(this Func<T1, T2, T3, T4, TResult> func, T1 param1, T2 param2)
{
return (p2, p3, p4) => func(param1, param2, p3, p4);
}

Kalau anda mengkikuti sampai sejauh ini maka selamat! Anda telah membuat semacam framework agar C# dapat melakukan currying!

Konversi dari C# Func ke F# FastFunc:

let Plot (from:float) (step:float) (final:float) (func:float -> float) =

Satu lagi, misal anda ingin menggunakan fungsi Plot di atas dalam program C#, maka kita akan menulis seperti ini:

Plotter.Plot(0.0, 1.0, 10.0, x => Math.Pow(x, 2));

Anda akan mendapati compile time error karena lambda expression dari C# itu adalah murni Delegate, sedangkan lambda expression di F# adalah bertipe FastFunc. Untuk melakukan konversi, gunakan fungsi ToFastFunc dari class FuncConvert sehingga perintah menjadi:

Plotter.Plot(0.0, 1.0, 10.0, FuncConvert.ToFastFunc(new Converter<double, double>(x => Math.Pow(x, 2))));

Atau biar lebih seamless, anda dapat membuat extension method seperti ini:

public static FastFunc<T, TResult> ToFastFunc<T, TResult>(this Func<T, TResult> func)
{
return FuncConvert.ToFastFunc(new Converter<T, TResult>(func));
}

Func<double,double> f = x => Math.Pow(x, 2);
Plotter.Plot(0.0, 1.0, 10.0, f.ToFastFunc());

Pretty simple eh?

Working on F# with NDepend

Steve — Sat, 28 Nov 2009 03:59:00 GMT

Following up from the earlier post here, looking more in depth at some of the results out of NDepend for my own little code quality project, and in addition to the results noted there

First out of the gate, for sanity's sake, when working with F#, it would make sense to add !HasAttribute OPTIONAL:System.Runtime.CompilerServices.CompilerGeneratedAttribute onto every rule. That way, you are not left to contemplate how and why the generated CompareTo methods on a simple record type

type Context = { Line : int; Column : int; EndLine : int; EndColumn : int }

can have an IL Cyclomatic complexity of 43.

A similar blanket exclusion should be applied to types whose names contain the sigil @ marking them as generated function objects. Unfortunately, compiler inserted write-once local variables do not have any such distinctive sigils by which they can be filtered, just unexciting normal names like str, str2.

It would be nice if the HasAttribute condition also allowed you to filter on properties of the attributes like !HasAttribute OPTIONAL:Microsoft.FSharp.Core.CompilationMappingAttribute WITH (SourceConstructFlags & 31 == 1) OR (SourceConstructFlags & 31 == 2) -- to filter record or sum types, which are rich in generated structure, where appropriate. For example, though the sum type

// After the Haskell type
type internal Either<'a, 'b> = | Left of 'a | Right of 'b

may be implemented into the CLR by making Either<'a, 'b> an abstract type with concrete inner types Either<'a, 'b>+Left and Either<'a, 'b>+Right, the headline Either<'a, 'b> type is not an abstract base class in the usual sense, that user written code will be expected to extend the type.

Similarly, while it is arguably an oversight of the F# code generation that none of the inner types within a sum type are marked as sealed -- there is no good case for extending them -- it would also be nice to be able to exclude all (implicitly, generated) types that derived from (or are an inner type of) a sum or record type from analysis; as well as all the content of types attributed with [CompilationMapping(SourceConstructFlags.NonpublicRepresentation | ...)].

Allowing names of the form |ActivePattern|_| is a trivial extension of the "names should be upper case" rule.

There is what looks like a bug in NDepend's analysis as it manages to make all the types I have derived from Microsoft.FxCop.Sdk.BaseIntrospectionRule pass the filter

DepthOfInheritance == 1 // Must derive directly from System.Object

The containing rule for that test Classes that are candidate to be turned into Structures could probably also benefit from having AND !IsStatic added, so as to exempt functional modules.

F# related job at Future Social Experiences (FUSE) Lab UK

dsyme — Fri, 27 Nov 2009 07:44:00 GMT

Are you interested in using probabilistic techniques to analyze online data and build new social experiences around it? The FUSE group located at Microsoft Research in Cambridge is hiring. The group use F# a lot and have applied it successfully on many projects.

https://careers.microsoft.com/JobDetails.aspx?jid=9575

The Future Social Experiences (FUSE) Lab UK team is a newly founded group co-located with Microsoft Research Cambridge. It will focus on new social experiences in Microsoft’s Online Services through computational intelligence technologies and through exploitation, combination and analysis of available data sources within and outside of Microsoft. In addition, the team’s charter is to bridge between Microsoft Research Cambridge, FUSE Labs, and Microsoft’s Online Services teams, including teams in Search, Ads & Portal in the Online Services Division (“Information Seekers”), teams in Office & SharePoint in Microsoft Business Division (“Information Workers”) and teams in Xbox Live and Window Mobile in the Entertainment and Devices Division (“Gamers and Mobile Workers”).

We are looking for mathematically astute, online-savvy applied researchers and developers. Necessary skills for this position include:

Ø Fit within an applied and basic research lab

Ø Development experience in various programming languages, including C++, C#, Python, SQL, F# and JavaScript

Ø Familiarity with Windows design tools and frameworks

Ø Development knowledge and experience of cloud applications and web services

Ø Ability to build throw-away/rapid prototypes

The successful candidate will be working in a small, dynamic and fun team reporting directly to the director of FUSE Labs UK.

If you are interested or require further information, please contact Ruth Lenton at cambhr@microsoft.com.

Custom Stack

Thu, 26 Nov 2009 07:00:11 GMT

This post describes the F# implementation of the custom stack from Chris Okasaki’s “Purely functional data structures”. namespace PurelyFunctionalDataStructures module CustomStack = type t<'a> = | Nil | Cons of ('a * t<'a>) let empty = Nil let isEmpty = function Nil -> true | _ -> false [...]

F# under the covers XI -- Literal expressions that aren't; attributes that don't

Steve — Thu, 26 Nov 2009 02:38:00 GMT

Consider the following simple C# property

public static FileShare get_Options()
{ return (FileShare.Delete | FileShare.Write);
}

This compiles in debug mode to

.method public hidebysig specialname static valuetype [mscorlib]System.IO.FileShare get_Options() cil managed
{ .maxstack 1 .locals init ( [0] valuetype [mscorlib]System.IO.FileShare CS$1$0000) L_0000: nop L_0001: ldc.i4.6 L_0002: stloc.0 L_0003: br.s L_0005 L_0005: ldloc.0 L_0006: ret }

which assigns the literal result -- 6 -- of the expression to the temporary that is then returned. The analogous F# method

 static member Options with get() = System.IO.FileShare.Delete ||| System.IO.FileShare.Write

or equivalently

 static member Options = System.IO.FileShare.Write ||| System.IO.FileShare.Delete

compiles to IL which preserves the expression to execute only at run time:

.method public specialname static valuetype [mscorlib]System.IO.FileShare get_Options() cil managed
{ .maxstack 4 L_0000: nop L_0001: ldc.i4.2 L_0002: ldc.i4.4 L_0003: or L_0004: ret }

which makes static analysis of the code in the more usually analysed state a rather more complicated business.

Another complicating factor is that while this syntax

 [<CoverageExemption( Points = 1, Justification = "Code generated is not a Literal")>] static member Options = System.IO.FileShare.Write ||| System.IO.FileShare.Delete

builds, it attaches the attribute (with Method and Constructor usage only) to the property as a whole; and not the generated get_Options method, as in

[CoverageExemption(Points=1, Justification="Code generated is not a Literal")]
public static FileShare Options
{ get { return (FileShare.Write | FileShare.Delete); }
}

What I'd like to express, and what I've not found a way to express, is

public static FileShare Options
{ [CoverageExemption(Points=1, Justification="Code generated is not a Literal")] get { return (FileShare.Write | FileShare.Delete); }
}

and MSDN remains opaque on the subject as well.

This is something I could code around, but I can't yet see a clean way of doing to allow separate attributes on the getters and the setters.

Later: The intended syntax for this option is, much as you might expect, this:

 static member Options with [<CoverageExemption( Points = 1, Justification = "Code generated is not a Literal")>] get() = System.IO.FileShare.Write ||| System.IO.FileShare.Delete

with the necessary insets as shown (to avoid error FS0010: Incomplete structured construct at or before this point in pattern), however on filing a bug report I got confirmation that it is a known issue with the Beta 2 release (aka October 2009 CTP), that this still decorates the property and not just the getter.

Using Erlang-style message passing from F# to coordinate asynchronous tasks in AutoCAD

Kean Walmsley — Thu, 26 Nov 2009 02:01:38 GMT

Simple spelling corrector in F#

Wed, 25 Nov 2009 23:34:41 GMT

This post is based on Peter Norvig’s How to write a spelling corrector, which is written in Python. His spell-checker ranks word-substitution candidates by their frequency in the language as determined by parsing some sources. He then gives different ways which could help make his algorithm more effective, such as taking the context into account (using n-grams). The [...]

Generating an IObservable from an IEvent in F#

Mon, 23 Nov 2009 19:39:29 GMT

Yesterday I showed how we can map some of the Rx operators to an API which looks more like the F# base classes. Today I wanted to use these mapped operators in a WPF-application written in F#.

F# gives us a nice way to use events as first class citizen (via IEvent) but these events implement their own version of IObservable<T> (in FSharp.Core.dll), which is unfortunately incompatible with the Rx version and therefore with the mapped API.

The solution I found is to wrap the F# IEvent with a Rx IObservable<T>:

/// Generates an observable from an IEvent
let fromEvent (event:IEvent<_,_>) =       
  Observable.Context 
     <- SynchronizationContexts.CurrentDispatcher
  Observable.Create<_>(fun x ->
    event.Subscribe(fun args -> x.OnNext(args))
      |> ignore
    new System.Action(fun () -> ()))      

Now we are able to use the WPF events as observables:

// Register ListBox Commands
listBox1.KeyDown
  |> Observable.fromEvent
  |> Observable.filter (fun args -> args.Key = Key.Delete)
  |> Observable.subscribe deleteElement

I am interested if someone has a different and maybe better solution to this problem.

Purely functional data structures in F# – introduction

Mon, 23 Nov 2009 12:01:53 GMT

This is the first of a series of posts relating to Chris Okasaki’s “Purely functional data structures” (see his thesis, and his book). Note : the code given in his aforementionned book assumes much more laziness than will be used in the coming examples, mainly for simplification purposes. In the following piece of code, we shall only [...]

Source Code for Programming F#

Mon, 23 Nov 2009 10:09:00 GMT

I've gotten a few requests recently for the source code of the examples in Programming F#. I've attached them as a series of F# Script files. In the ZIP file you'll find a few gems such as:

A 'state' computation expression
Examples of F# Asynchronous Workflows and the Parallel Extensions to .NET
References for writing OO code in F#, including advanced stuff like Delegates and Events
Code for F# interop such as P/Invoke signatures

And as always, any code released on this blog it comes with the standard disclaimer:

All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose. So in other words, if the attached source files cause you any grief whatsoever you can’t blame me, O'Reilly Media, or Microsoft.

My PDC session is online - “Future directions for C# and Visual Basic”

Mon, 23 Nov 2009 05:17:44 GMT

In case you are training to play the part of a first generation Italian immigrant in a Broadway show or if you want to understand why I never short msft stock: http://microsoftpdc.com/Sessions/FT11

Book Review: Debug It! (Paul Butcher, Pragmatic Bookshelf)

Sun, 22 Nov 2009 15:24:41 GMT

Paul asked me to review this, his first book, and my comment to him was that he had a pretty high bar to match; being of the same "series" as Release It!, Mike Nygard's take on building software ready for production (and, in my repeatedly stated opinion, the most important-to-read book of the decade), Debug It! had some pretty impressive shoes to fill. Paul's comment was pretty predictable: "Thanks for keeping the pressure to a minimum."

My copy arrived in the mail while I was at the NFJS show in Denver this past weekend, and with a certain amount of dread and excitement, I opened the envelope and sat down to read for a few minutes. I managed to get halfway through it before deciding I had to post a review before I get too caught up in my next trip and forget.

Short version

Debug It! is a great resource for anyone looking to learn the science of good debugging. It is entirely language- and platform-agnostic, preferring to focus entirely on the process and mindset of debugging, rather than on edge cases or command-line switches in a tool or language. Overall, the writing is clear and straightforward without being preachy or judgmental, and is liberally annotated with real-life case stories from both the authors' and the Pragmatic Programmers' own history, which keeps the tone lighter and yet still proving the point of the text. Highly recommended for the junior developers on the team; senior developers will likely find some good tidbits in here as well.

Long version

Debug It! is an excellently-written and to-the-point description of the process of not only identifying and fixing defects in software, but also of the attitudes required to keep software from failing. Rather than simply tossing off old maxims or warming them over with new terminology ("You should always verify the parameters to your procedure calls" replaced with "You should always verify the parameters entering a method and ensure the fields follow the invariants established in the specification"), Paul ensures that when making a point, his prose is clear, the rationale carefully explained, and the consequences of not following this advice are clearly spelled out. His advice is pragmatic, and takes into account that developers can't always follow the absolute rules we'd like to—he talks about some of his experiences with "bug priorities" and how users pretty quickly figured out to always set the bug's priority at the highest level in order to get developer attention, for example, and some ways to try and address that all-too-human failing of bug-tracking systems.

It needs to be said, right from the beginning, that Debug It! will not teach you how to use the debugging features of your favorite IDE, however. This is because Paul (deliberately, it seems) takes a platform- and language-agnostic approach to the book—there are no examples of how to set breakpoints in gdb, or how to attach the Visual Studio IDE to a running Windows service, for example. This will likely weed out those readers who are looking for "Google-able" answers to their common debugging problems, and that's a shame, because those are probably the very readers that need to read this book. Having said that, however, I like this agnostic approach, because these ideas and thought processes, the ones that are entirely independent of the language or platform, are exactly the kinds of things that senior developers carry over with them from one platform to the next. Still, the junior developer who picks this book up is going to still need a reference manual or the user manual for their IDE or toolchain, and will need to practice some with both books in hand if they want to maximize the effectiveness of what's in here.

One of the things I like most about this book is that it is liberally adorned with real-life discussions of various scenarios the author team has experienced; the reason I say "author team" here is because although the stories (for the most part) remain unattributed, there are obvious references to "Dave" and "Andy", which I assume pretty obviously refer to Dave Thomas and Andy Hunt, the Pragmatic Programmers and the owners of Pragmatic Bookshelf. Some of the stories are humorous, and some of them probably would be humorous if they didn't strike so close to my own bitterly-remembered experiences. All of them do a good job of reinforcing the point, however, thus rendering the prose more effective in communicating the idea without getting to be too preachy or bombastic.

The book obviously intends to target a junior developer audience, because most senior developers have already intuitively (or experientially) figured out many of the processes described in here. But, quite frankly, I think it would be a shame for senior developers to pass on this one; though the temptation will be to simply toss it aside and say, "I already do all this stuff", senior developers should resist that urge and read it through cover to cover. If nothing else, it'll help reinforce certain ideas, bring some of the intuitive process more to light and allow us to analyze what we do right and what we do wrong, and perhaps most importantly, give us a common backdrop against which we can mentor junior developers in the science of debugging.

One of the chapters I like in particular, "Chapter 7: Pragmatic Zero Tolerance", is particularly good reading for those shops that currently suffer from a deficit of management support for writing good software. In it, Paul talks specifically about some of the triage process about bugs ("When to fix bugs"), the mental approach developers should have to fixing bugs ("The debugging mind-set") and how to get started on creating good software out of bad ("How to dig yourself out of a quality hole"). These are techniques that a senior developer can bring to the team and implement at a grass-roots level, in many cases without management even being aware of what's going on. (It's a sad state of affairs that we sometimes have to work behind management's back to write good-quality code, but I know that some developers out there are in exactly that situation, and simply saying, "Quit and find a new job", although pithy and good for a laugh on a panel, doesn't really offer much in the way of help. Paul doesn't take that route here, and that alone makes this book worth reading.)

Another of the chapters that resonates well with me is the first one in Part III ("Debug Fu"), Chapter 8, entitled "Special Cases", in which he tackles a number of "advanced" debugging topics, such as "Patching Existing Releases" and "Hesenbugs" (Concurrency-related bugs). I won't spoil the punchline for you, but suffice it to say that I wish I'd had that chapter on hand to give out to teammates on a few projects I've worked on in the past.

Overall, this book is going to be a huge win, and I think it's a worthy successor to the Release It! reputation. Development managers and team leads should get a copy for the junior developers on their team as a Christmas gift, but only after the senior developers have read through it as well. (Senior devs, don't despair—at 190 pages, you can rip through this in a single night, and I can almost guarantee that you'll learn a few ideas you can put into practice the next morning to boot.)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

F# Discoveries This Week 11/22/2009

Sun, 22 Nov 2009 07:49:52 GMT

Over this past week at PDC I was lucky enough to see some fantastic sessions and spend time with members of the F# and greater Visual Studio language teams. Naturally, these experiences have left me both floored and swimming in new ideas. This edition of Discoveries This Week includes both the very best of what I saw at PDC 2009 and the most outstanding things I’ve glimpsed going on in the F# community. Please do enjoy.

Reflection on the PDC Keynotes

For the most information in the shortest amount of time I suggest watching the day one and day two PDC keynotes. They are both jam packed with exciting announcements and demos. While at PDC I wrote about my experience watching these here (day one) and here (day two).

Microsoft Perspectives on the Future of Programming

Come hear from several of the Microsoft senior technical leaders about the future of programming, programming languages, and tools.

If you watch just one PDC session let this be it.

With Butler Lampson, Erik Meijer, Don Box, Jeffrey Snover, Herb Sutter, and Burton Smith, Microsoft’s best gathered to debate the future of programming in a twitter driven panel at PDC. I was happy to be able to contribute with a question on type systems which erupted into quite a disagreement. I will be writing about this session at length, and reflecting on my past thoughts about this topic, in the near future.

Luke Hoban’s F# for Parallel and Asynchronous Programming

F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. Come hear the core concepts of the F# language, and see how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.

By combining small, easily understood, ideas Luke constructs F#’s big picture in the most engaging way I’ve seen to date. This is now my go to talk for people who are interested in, but new to, the F# programming language.

Jomo Fisher’s F# Scripting, .NET 4.0 and Mixed-mode assemblies

One of the recent problems we’ve seen is that, because of the support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies. These assemblies are, for example, those that are compiled from C++\CLI. Currently available DirectX assemblies are mixed mode.

This clever approach to switching the F# REPL to 2.0 binding mode is particularly handy to know.

Matthew Moloney’s Collaborative Development Using F# Interactive

This is a proof of concept of an interactive collaborative development environment I built using F# Interactive. The aim here is to explore different ideas for further development, not so much as to present an alternative to Visual Studio.

I couldn’t pass this very cool idea up. I can’t help but think about extending this to full feldged explorative programming community websites.

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

The goal of this blog post is to make you aware of F# support in Silverlight in Visual Studio 2010. In addition, this blog post shows an example why F# is going to be very important for Silverlight architects and developers. Note: This is NOT an intro to F#.

A great post. I am always interested in seeing concrete examples of F# adding value to existing technologies and platforms. I have a sneaking suspicion that there are very few places where it won’t.

F# -- a few notes and something to play with

Steve — Sun, 22 Nov 2009 06:42:00 GMT

`Seq.take<'T>`

While F# documentation is there on MSDN, it is a little sketchy. For example, take Seq.take<'T>:

Return the first N elements of the sequence.

Contrast, for example, Scala's Seq[A].take

Returns a sequence consisting only over the first n elements of this sequence, or else the whole sequence, if it has less than n elements. (non-strict)

So, what happens when you take too much in F#?

Answer: an exception is thrown indicating too few elements in the collection.

It's not just Scala -- Haskell, Erlang lists:sublist and -- most tellingly -- OCaml all define an "up to N" behaviour for a take style operation. (So I've submitted this one as a bug report).

Later: Actually what I was looking for is Seq.truncate.

And that was one of today's little gotchas…

Generated names for `fun`s

In the February CTP release the class representing a fun in method MyMethod of class My.FullyQualified.ClassName at line ### was named My.FullyQualified.ClassName+MyMethod@### with clashes resolved by adding an incrementing count suffix like -#.

In the October CTP, the name is now <StartupCode$My-FullyQualified>.$ClassName+MyMethod@### plus possible suffix as before.

A release

I mentioned yesterday about getting close to calling a little toolset I've been working on to something I could call 1.0 state -- which basically means it seems to do what I want it to do in test for the intended feature set, I have no outstanding bugs, and all the low-hanging refactoring and more has been done (though it's not complete and really never can be, and it could probably do with more comments).

So, it works with nCover format coverage files and FxCop to provide coverage analysis and reporting -- separating out code that isn't covered in test as to why that might be the case, like for its own solution, a mix of C# and F# projects:

Legend

Uncovered code
User exempted
Generated code
Statically analyzed
Covered code

Modules summary

CSharpTests

100%

Tinesware.Infrastructure

10.53%

78.95%

Tinesware.InfrastructureTests

3.57%

7.14%

25%

64.29%

Tinesware.Rules

9.31%

2.09%

0.48%

88.12%

Tinesware.TestData

3.23%

24.19%

12.9%

62.9%

3.23%

Use it like this

rem Generate coverage.xml
ncover.console.exe nunit-console.exe [unit test assembly] /noshadow //reg //a rem run FxCop over the files in the same directory
FxCopCmd.exe /f:[file to analyse] [/f:[file to analyse] ... ] /rule:\path\to\Tinesware.Rules.dll "/rule:\path\to\Microsoft FxCop 1.36\Rules" ...

Then view the generated AnalyzedCoverage.xml file in a browser using the supplied coverage.xsl file (copied to the same folder).

More discussion of the road ahead on my other blog.

Source and binaries are in my Works In Progress folder here. Bug reports and enhancement requests welcome -- turnround may not be speedy as I'll probably pick up something else from my stack to work on next, but will be added to the queue.

F# under the covers X -- the curious case of record types

Steve — Sat, 21 Nov 2009 06:00:00 GMT

They're coming thick and fast now...

Define a record type such as

type Context = { Line : int; Column : int; EndLine : int; EndColumn : int }

The class that results looks like

[Serializable, CompilationMapping(SourceConstructFlags.RecordType)]
public sealed class Context : IStructuralEquatable, IComparable, IStructuralComparable
{ // Fields [DebuggerBrowsable(DebuggerBrowsableState.Never)] internal int Column@; [DebuggerBrowsable(DebuggerBrowsableState.Never)] internal int EndColumn@; [DebuggerBrowsable(DebuggerBrowsableState.Never)] internal int EndLine@; [DebuggerBrowsable(DebuggerBrowsableState.Never)] internal int Line@; // Methods public Context(int line, int column, int endLine, int endColumn); [CompilerGenerated] public sealed override int CompareTo(object obj); [CompilerGenerated] public int CompareTo(Context obj); [CompilerGenerated] public sealed override int CompareTo(object obj, IComparer comp); [CompilerGenerated] public sealed override bool Equals(object obj); [CompilerGenerated] public bool Equals(Context obj); [CompilerGenerated] public sealed override bool Equals(object obj, IEqualityComparer comp); [CompilerGenerated] public sealed override int GetHashCode(); [CompilerGenerated] public sealed override int GetHashCode(IEqualityComparer comp); // Properties [CompilationMapping(SourceConstructFlags.Field, 1)] public int Column { get; } [CompilationMapping(SourceConstructFlags.Field, 3)] public int EndColumn { get; } [CompilationMapping(SourceConstructFlags.Field, 2)] public int EndLine { get; } [CompilationMapping(SourceConstructFlags.Field, 0)] public int Line { get; }
}

where the source context for each method is the same -- the range containing just the type name.

Now, you wouldn't expect anything to be seriously unusual about this class in terms of its implementation, but there is.

FxCop reminds you about the IComparable should-haves that can't be enforced through interface constraints:

[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '!=' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '<' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '==' since it implements IComparable.
[Location not stored in Pdb] : warning : CA1036 : Microsoft.Design : 'Context' should define operator '>' since it implements IComparable.

but which aren't there; and Reflector's decompilation to C# is stymied by the highlighted CompareTo overloads -- the simple one is implemented as

[CompilerGenerated]
public sealed override int CompareTo(object obj)
{ return this.CompareTo((Context) obj);
}

which fortunately doesn't give much scope for things to go wrong.

In this and the previous case, the offending instruction that Reflector balks at is a simple branch such as indicated in this example

 L_0045: ldc.i4.m1 L_0046: nop L_0047: br.s L_0050 L_0049: ldloc.s num2 L_004b: ldloc.s num3 L_004d: cgt L_004f: nop L_0050: stloc.2

It's quite clear at every turn that F# is coming at the problem of code generation from a very different direction to the well explored parts of the phase space of valid IL that C# and VB.net dabble in. And clear, too, that this will present a significant challenge to all writers of tools to work with the language -- it takes us well out of our old comfort zone.

F# under the covers IX -- the case of the missing coverage

Steve — Fri, 20 Nov 2009 23:20:00 GMT

As I'm driving my little set of FxCop rules and associated helpers to a state I feel comfortable with calling a 1.0 release, I'm looking in more detail at how the code coverage in the automated system/integration test is going, trying to drive that towards 100%. And as usual, the F# code generation is throwing up some interesting results.

Take this method (lightly refactored from last time):

 member private self.CheckStatic (fn:Method) (xml:Option<XElement>) = if match fn with | SimpleGetter -> Resolved | SimpleSetter -> Resolved | SimpleConstructor -> Resolved | Stub -> Resolved | CSharpVoidStub -> Resolved | CSharpThrowsStub -> Resolved | CSharpConstStub -> Resolved | _ -> Open = Resolved then MarkXml xml StaticAnalysisExempt Int32.MaxValue "Static" match CoverageExemptionRule.GetAttribute ("Tinesware.Infrastructure", "CoverageExemptionAttribute") fn fn.DeclaringType.DeclaringModule with | None -> () | _ -> self.Problems.Add(new Problem(self.GetNamedResolution("attributeStatic", fn.FullName), fn)) Resolved else Open

Although my tests give a match for every case in the pattern -- and nCover shows a visit for every line from 168 to 176, and the expression body of each branch of the if/else, it also claims that a code point that spans from from line 168 col 5 to line 177 col 24 (everything from if to then inclusive) is not visited.

Unfortunately, the IL generated for this method is not back-compilable to C# in Reflector (yes, another problem report submitted), so I can't use that to analyse what is going on in this particular case : I shall have to inject some diagnostic code into the rule itself to see what FxCop thinks is going on as a statement which spans those lines.

But this isn't the only mysterious bit of uncoverage I've found in F# code -- in the previous state of the method (as showcased here), it was the identifier result in let result = match… that got the uncoverage, despite the named value being used as the final expression in the method.

In most cases, it is possible to refactor away such temporaries, and clear the spurious uncoverages that they give rise to; but, as this example shows, it is not always possible.

Later

By recursively dumping Statements in FxCop for this method (which inserted 2 lines in a routine above this one, thus displacing the line numbers), I get a lot of multiple hits on statements (same type, same source context range), but the only ones with the appropriate source context are

Block -> from 170 : 5 to 179 : 24
Nop -> from 170 : 5 to 179 : 24
Nop -> from 170 : 5 to 179 : 24
AssignmentStatement -> from 170 : 9 to 170 : 22
AssignmentStatement -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 170 : 9 to 170 : 22
Branch -> from 170 : 9 to 170 : 22
Block -> from 171 : 27 to 171 : 35
ExpressionStatement -> from 171 : 27 to 171 : 35
Nop -> from 171 : 27 to 171 : 35
…

So it seems that first Nop pair, with no other statement occupying the the same range, may be what it being detected as uncovered (unlike the second Nop, which overlaps the immediately preceding ExpressionStatement exactly).

The equivalent IL looks like

.method assembly instance class Tinesware.Rules.Assist.Inconclusive CheckStatic(class [Microsoft.Cci]Microsoft.FxCop.Sdk.Method fn, class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [System.Xml.Linq]System.Xml.Linq.XElement> xml) cil managed
{ .custom instance void [Tinesware.Infrastructure]Tinesware.Infrastructure.CoverageExemptionAttribute::.ctor() = { Points=int32(0x10) Justification=string('Operationally tested') } .custom instance void [mscorlib]System.Diagnostics.CodeAnalysis.SuppressMessageAttribute::.ctor(string, string) = { string('Microsoft.Usage') string('CA1801:ReviewUnusedParameters') MessageId=string('xml') Justification=string('Required signature') } .custom instance void [FSharp.Core]Microsoft.FSharp.Core.CompilationArgumentCountsAttribute::.ctor(int32[]) = { new int32[int32(2)] { int32(1), int32(1) } } .maxstack 9 .locals init ( [0] class Tinesware.Rules.Assist.Inconclusive inconclusive, [1] class [Microsoft.Cci]Microsoft.FxCop.Sdk.Method 'method', [2] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option, [3] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option2, [4] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option3, [5] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option4, [6] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option5, [7] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option6, [8] class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> option7, [9] class Tinesware.Rules.Assist.Inconclusive inconclusive2, [10] class [FSharp.Core]System.Tuple`2<string, string> tuple, [11] class [Microsoft.Cci]Microsoft.FxCop.Sdk.Method method2, [12] class [Microsoft.Cci]Microsoft.FxCop.Sdk.ModuleNode node) L_0000: nop L_0001: nop L_0002: ldarg.1 L_0003: stloc.1 L_0004: ldloc.1 L_0005: call class [FSharp.Core]Microsoft.FSharp.Core.FSharpOption`1<class [FSharp.Core]Microsoft.FSharp.Core.Unit> Tinesware.Rules.Patterns::|SimpleGetter|_|(class [Microsoft.Cci]Microsoft.FxCop.Sdk.Method) L_000a: stloc.2 L_000b: ldloc.2 L_000c: brfalse.s L_0010 L_000e: br.s L_0012 L_0010: br.s L_001d L_0012: call class Tinesware.Rules.Assist.Inconclusive Tinesware.Rules.Assist.Inconclusive::get_Resolved() L_0017: nop

which does indeed have a pair of Nop opcodes at the start.

So, that looks like another heuristic to add - removing unvisited code point records that correspond to nothing but a Nop.

Left-Truncatable Primes

phil — Thu, 19 Nov 2009 16:17:00 GMT

Yesterday a colleague asked me how a function to calculate the nth left-truncatable prime might look in F# for comparison against a C++ implementation, so lets start with the definition from Wikipedia:

In number theory, a left-truncatable prime is a prime number which, in a given base, contains no 0, and if the leading ("left") digit is successively removed, then all resulting numbers are prime. For example 9137, since 9137, 137, 37 and 7 are all prime. Decimal representation is often assumed and always used in this article.

The following is the F# implementation, using recursion, coded up on the train home last night (the function takes about 5ms to calculate the 1000th left-truncatable prime, just 2ms off very close to the optimized C++ time):

let IsPrime n = if n = 1 then false else let max = n |> float |> sqrt |> int let rec Test = function | x when x > max -> true | x -> if (n % x) = 0 then false else Test (x+1) Test 2 let NthLeftTruncatedPrime index = let rec Find digit factor primes primes' count acc = match digit, primes' with | 10, _ -> let primes = List.rev acc Find 1 (10*factor) primes primes count [] | _, [] -> Find (digit+1) factor primes primes count acc | _, prime::tail -> let k = (digit * factor) + prime let count, acc = if IsPrime k then count+1, k::acc else count, acc if count = index then k else Find digit factor primes tail count acc let primes = [2;3;5;7] if index <= 4 then List.nth primes (index-1) else Find 1 10 primes primes 4 []

Initially the comparison was intended to be simply on readability, where the F# code was unsurprisingly found to be shorter, and the imperative style (lots of for loops) of the C++ code more familiar to some.

Just out of curiosity I ran a quick performance check to see whether performance was in the same order of magnitude, fully expecting the C++ to faster. In fact initially the C++ was half the speed of the F# code (i.e. the C++ took twice as long). After a little head scratching, I tried a few teaks on the C++, for example giving the STL vector an initial capacity which increased performance by about 20%. Then I spotted that the C++ was using Int64 underneath and the F# Int32. Making the C++ use Int32 brought comparable performance to the F# code give or take a millisecond. At no point did I bother trying to optimize the F# code (except for running the function once before doing the timing to ensure the code had been just-in-time (JIT) compiled).

At the time of first posting this entry it was thought that the C++ was a couple of milliseconds faster. Actually later in the day it was found that there was an error in the calculation of the C++ result and in fact there was no discernable difference between the performance of the C++ and F# code. There are further algorithmic optimizations that could be applied to both implementations but I will leave that as an exercise for the reader.

This is quite interesting, it really does show that you can *NOT* assume that writing code in unmanaged C++ will intrinsically make it faster than code written in managed languages like C# and F#.

Planet F#

Fun with Functional - Currying di C#

Apa itu Currying?

Enough Talking About F#, I’m a C# Folks!

Konversi dari C# Func ke F# FastFunc:

Working on F# with NDepend

F# related job at Future Social Experiences (FUSE) Lab UK

Custom Stack

And also …

F# under the covers XI -- Literal expressions that aren't; attributes that don't

Using Erlang-style message passing from F# to coordinate asynchronous tasks in AutoCAD

Simple spelling corrector in F#

And also …

Generating an IObservable from an IEvent in F#

Purely functional data structures in F# – introduction

And also …

Source Code for Programming F#

My PDC session is online - “Future directions for C# and Visual Basic”

Book Review: Debug It! (Paul Butcher, Pragmatic Bookshelf)

Short version

Long version

F# Discoveries This Week 11/22/2009

Reflection on the PDC Keynotes

Microsoft Perspectives on the Future of Programming

Luke Hoban’s F# for Parallel and Asynchronous Programming

Jomo Fisher’s F# Scripting, .NET 4.0 and Mixed-mode assemblies

Matthew Moloney’s Collaborative Development Using F# Interactive

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

F# -- a few notes and something to play with

Seq.take<'T>

Generated names for funs

A release

Legend

Modules summary

F# under the covers X -- the curious case of record types

F# under the covers IX -- the case of the missing coverage

Later

Left-Truncatable Primes

`Seq.take<'T>`

Generated names for `fun`s