I'm sorry Dave, I'm afraid I can't do that.

Joe Duffy points to the announcement that the Developer Division at Microsoft is folding F# into the 'official' set of supported .NET languages. This is great news.

I don't normally write about my job, so I'm going to write about a different one that could be yours...

My team has vacancies. We design, develop and support equity-derivatives trading systems for one of Australia's foremost financial institutions for markets at home and abroad. You'd like to work in a small, highly-skilled team of software developers and have some or all of the following:

• Strong C++ and optionally VB6 and/or .NET
• Significant experience of multi-threaded server application development
• SQL experience (preferably SQL Server)
• A solid understanding of IP-based communication protocols
• A working knowledge of equity-derivative products
• A working knowledge of client-side development

You will be a self-starter who can work with minimum supervision on projects from inception through delivery and onto support, across the various architectural tiers. You will be comfortable communicating with the key business stake-holders, primarily traders and business managers and be focused on delivering solutions that meet their needs.

Successful applicants would fill vacancies at our Sydney offices and should hold either Australian Citizenship or Permanent Residence. (There are opportunities abroad also).

If you're interested, please drop me a line via my gmail address (nagunn at ...) and we can take it from there.

My inexperience with F# has caught me out. Robert Pickering has an article on asynchronous workflows (similar concept to CCR iterators) in which he mentions a forthcoming article on 'mailboxes', the message-passing feature I said didn't exist. I look forward to it.

...and why productivity and pragmatism are important too. The last two paragraphs are especially interesting.

So I rushed ahead of myself a bit and though that I'd try and implement a DSS service in F#. I've posted below what I think is the equivalent code for the default DSS service you get when you create a new DSS simple service project. There are three salient points:

1. I've collapsed the *Types and *Service into a single file.
2. The support for CCR iterators in the handler methods is a little bit of a hack (my hack).
3. It doesn't work. It doesn't even compile.

(3) is clearly the most salient point. DSS requires that the Contract class in a service namespace expose a string literal called 'Identifier' that contains the contract URI. Unfortunately, the code listed below doesn't expose a string literal but rather a read-only property. CLR aficionados will know that the difference is that clients that refer to 'Contract.Identifier' via a literal end up with that literal in their own assembly so that if that literal changes in the source assembly, pre-existing dependent assemblies don't reflect that change.

[BTW, don't change contract identifiers like this. Treat them as web-shaped GUIDs].

Unfortunately, F# does not currently support const literals. So you cannot currently write DSS services in F#. Which is a shame because I think the code could be a slight improvement on the C# equivalent.

Incidentally, it doesn't compile simply because of the use of Contract.Identifier in the ContractAttribute. As a read-only property, this is a runtime evaluation, not a compile-time one so cannot be used in an attribute constructor. This can be fixed by just replacing the symbolic property with its literal value. However, the DSS runtime still fails to find a Contract class of the right shape.

There are some differences also in the implementation of the handler methods, due to the current limitations of computation expressions, the primary one being (approximately) that such expressions can only yield results directly - you can't write 'regular' code between yields. The workaround for this is to yield functions that contain the regular code and each return an ITask, then have another computation expression that yields the result of those functions. The following snippets from an F# file of CCR helpers illustrate this:

#light

open System
open Microsoft.Ccr.Core

let deref (x : seq<unit -> ITask>) = (seq { for f in x do yield f() }).GetEnumerator()
let handler x = Arbiter.FromHandler(new Handler(x))

let receive<'a> persist (port : Port<'a>) handler = 
    Arbiter.Receive(persist, port, new Handler<'a>(handler))
let receive_one<'a> (port : Port<'a>) = receive false port 
let receive_many<'a> (port : Port<'a>) = receive true port 

let receive_with_iterator<'a> persist (port : Port<'a>) handler =
    Arbiter.ReceiveWithIterator(persist, port, new IteratorHandler<'a>(fun(a) -> 
        deref(handler(a))))
let receive_one_with_iterator<'a> (port : Port<'a>) = 
    receive_with_iterator false port
let receive_many_with_iterator<'a> (port : Port<'a>) = 
    receive_with_iterator true port

let activate_many taskQueue tasks = 
    Arbiter.Activate(taskQueue, [| for t in tasks -> t :> ITask |] )

let activate taskQueue task = 
    activate_many taskQueue [| task |]

let ( &= ) taskQueue task = 
    activate taskQueue task

And here's an example of using them

let port = new Port<int>()

taskQueue &= (receive_many_with_iterator port (fun i -> 
    print_endline ("Triggered.")
    seq {
        yield fun() ->
            receive_one port (fun i -> print_endline (i.ToString()))
        yield fun() ->
            receive_one port (fun i -> print_endline (i.ToString()))
    }))

port.Post(1)
port.Post(2)
port.Post(3) 

Anyway, I digress. Here's the code for the service. My F# experience is minimal, so I'd be happy to hear about any improvements to any of this code.

#light

namespace Iodyne.Drivers.Tcp.Connection

open System
open System.ComponentModel
open System.Net
open System.Net.Sockets
open Microsoft.Ccr.Core
open Microsoft.Dss.Core.Attributes
open Microsoft.Dss.ServiceModel.Dssp
open Microsoft.Dss.ServiceModel.DsspServiceBase;
open W3C.Soap

open Ccradaptors;

type Contract = class
    static member Identifier = "http://iodyne.blogspot.com/2007/10/driver/tcp/connection"
end

[<DataContract>]
type State = class
    new() = {}
end

type Get = class
    inherit Get<GetRequestType, PortSet<State, Fault>>
    new() = {}
    new(body : GetRequestType) = 
        { inherit Get<GetRequestType, PortSet<State, Fault>>(body) }
    new(body : GetRequestType, response : PortSet<State, Fault>) = 
        { inherit Get<GetRequestType, PortSet<State, Fault>>(body, response) }
end

[<ServicePort>]
type Operations = class 
    inherit PortSet<DsspDefaultLookup, DsspDefaultDrop, Get>
    new() = {}
end

[<DisplayName("TcpConnection"); 
  Description("TcpDriver Connection Service"); 
  ContractAttribute(Contract.Identifier)>]
type Service = class
    inherit DsspServiceBase as base
    [<ServicePort(AllowMultipleInstances = true)>]
    val mainPort : Operations
    val state : State
    
    new(creationPort : DsspServiceCreationPort) = {
        inherit DsspServiceBase(creationPort) ;
        state = new State()
        mainPort = new Operations() }
    
    override this.Start() = 
        base.Start()
    
    [<ServiceHandler(ServiceHandlerBehavior.Concurrent)>]
    member this.GetHandler(get : Get) = 
        enumerate 
            (seq {
                 yield (handler (fun () -> get.ResponsePort.Post(this.state)))
            })
end 

I mentioned a while back that I'd read Joe Armstrong's PhD thesis on building reliable distributed systems. Early on, Joe introduces Erlang, a language he and his team designed at Ericsson to build large-scale, fault-tolerant, concurrent systems.

I've no background at all in functional languages, but I was struck by 4 things (in no particular order):

1. The code seemed to have hit a sweet-spot of readability and brevity. It's a compact syntax.
2. The support of functions as first-class types (a feature of functional languages), allowed for some simple but powerful constructs.
3. A lot of type inference (and a lot less typing!)
4. Language support for message-passing primitives.

I won't expand particularly on these right now, but some of these features have crept into C#, notably limited type inference (i.e. the var keyword) and lambda functions (via succinct syntax for anonymous delegates).

Anyway, whilst reading round Erlang and functional languages in general, I discovered F#, a research language from the Microsoft Research group at Cambridge University, England.  F# is a CLR language, with strong functional influences but with support also for imperative and object-oriented programming. (One of the principal developers, Don Syme, was one of the guys who worked out how to do generics on the CLR).

F# shares with Erlang the first 3 points above. And that got me thinking that the CCR, integrated through the F# could provide the fourth. You can use the CCR directly from F#, but wrapper functions make it easier still to add powerful concurrency and co-ordination support for task-based programming directly into F# in a natural way, and I'll blog about these in forthcoming posts.

BTW, someone is building Erlang.NET!