Phillip Trelford's Array

POKE 36879,255

F# Exchange 2015

This Friday saw the first ever F# eXchange, a one-day 2 track conference dedicated to all things F#, hosted at Skills Matter in London and attracting developers from across Europe.

There was a strong focus on open source projects throughout the day including MBrace (data scripting for the cloud), Fake (a DSL for build tasks), Paket (a dependency manager for .Net), the F# Power Tools and FunScript (an F# to JS compiler). In fact all the presenters used the open source project FsReveal to generate their slides!


Tomas Petricek opened proceedings with a keynote on The Big F# and Open Source Love Story:

Slow development

One of Tomas’s observations, on slow development for open source projects resonated with many, where successful projects often start as just a simple script that fulfils a specific need and slowly gather momentum over time.

As an example, in Steffen Forkmann’s presentation he talked about how Fake had started as a simple F# script and over the years seen more and more contributors and downloads, with the addition of high quality documentation having a huge impact:


All the talks were recorded, and all the videos are already online!


The videos:

Steffen also took advantage of his talk to make a special announcement about Paket:


The day ended with some pizza, drinks and a panel organized by prolific F# contributor, Don Syme:

Panel Discussion

Each panel member pitched why they thought F# was good in their core domain area from cloud, games, design, data science, scripting through to web.

There were some interesting discussions, and some mentions of the recent fsharpWorks led F# Survey.


The date for next year’s F# eXchange 2016, the 16th April, is already in the calendar, hope to see you there, and please take advantage of the early bird ticket offer, only 85GBP up until the 16th June!

String and StringBuilder revisited

I came across a topical .Net article by Dave M Bush published towards the tail end of 2014 entitled String and StringBuilder where he correctly asserts that .Net’s built-in string type are reference types and immutable. All good so far.

The next assertion is that StringBuilder will be faster than simple string concatenation when adding more than 3 strings together, which is probably a pretty good guess, but lets put it to the test with 4 strings.

The test can be performed easily using F# interactive (built-in to Visual Studio) with the #time directive:

open System.Text


let a = "abc"
let b = "efg"
let c = "hij"
let d = "klm"

for i = 1 to 1000000 do
   let e = StringBuilder(a)
   let f = e.Append(b).Append(c).Append(d).ToString() 
// Real: 00:00:00.317, CPU: 00:00:00.343, GC gen0: 101, gen1: 0, gen2: 0
for i = 1 to 1000000 do
   let e = System.String.Concat(a,b,c,d)
// Real: 00:00:00.148, CPU: 00:00:00.156, GC gen0: 36, gen1: 0, gen2: 0

What we actually see is that for concatenating 4 strings StringBuilder takes twice as long as using String.Concat (on this run 0.317ms vs 0.148ms) and generates approximately 3 times as much garbage (gen0: 101 vs gen0: 36)!

Underneath the hood the StringBuilder is creating an array to append the strings into. When appending if the current buffer length is exceeded (the default is 16) then a new array must be created. When ToString is called it may, based on a heuristic, decide to return the builder’s array or allocate a new array and copy the value into that. Therefore the performance of StringBuilder is dependent on the initial capacity of the builder and the number and lengths of the strings to append.

In contrast, String.Concat (which the compiler resolves the ‘+’ operator to) calculates the length of the concatenated string from the lengths of the passed in strings, then allocates a string of the required size and copies the values in, ergo, in many scenarios it will require less copying and less allocation.

When concatenating 2, 3 or 4 strings we can take advantage of String.Concat’s optimized overloads, after this the picture changes as an array argument must be passed which requires an additional allocation. However String.Concat may still be faster than StringBuilder in some scenarios where the builder requires multiple reallocations.

But wait there’s more, going back to the ‘+’ operator, if we assign the integer literal expression 1 + 2 + 3 the compiler can reduce the value to 6, equally if we define the strings as const string then the compiler can apply the string concatenations at compile time leading to, in this contrived example, no cost whatsoever.

The moral of the story is when it comes to performance optimization - measure, measure, measure.

Parsing with SNOBOL

Just before Christmas I came across some Java source code by “Uncle” Bob Martin aimed at “demystifying compilers” which expends about 600 lines of code to parse the following simple finite state machine:

Actions: Turnstile
FSM: OneCoinTurnstile
Initial: Locked
Locked Coin Unlocked {alarmOff unlock}
Locked Pass Locked  alarmOn
Unlocked Coin Unlocked thankyou
Unlocked Pass Locked lock

For fun I knocked up a broadly equivalent parser in F# using FParsec which was just under 40 lines of code, and posted the code on this blog.

The post generated some interest, and I even got a mention on Twitter from “Uncle” Bob himself:

I’d not seen SNOBOL before, but given Mr Martin’s recommendation I popped over to the SNOBOL page on WikiPedia and liked what I saw:

SNOBOL rivals APL for its distinctiveness in format and programming style, both being radically unlike more "standard" procedural languages such as BASIC, Fortran, or C.

SNOBOL first appeared in 1962 and appears to have been popular in US Universities as a text manipulation language in the 70s and 80s. The language supports pattern matching over text combined with assembler like control flow using labels and goto (like C#).

As a text manipulation language, SNOBOL code feels a little more readable than the new norm - regular expressions .

If you’d like to take it out for a spin there’s an open source SNOBOL IDE, with syntax colouring support, for Linux and Windows called TkS*LIDE.

SNOBOL Interpreter

Nowadays when I want to learn a new language I often start by implementing it, to this end over the course of about a week I built a SNOBOL interpreter with just enough functionality to run the samples on the Wikipedia page along with some more involved samples from other sources.

The SNOBOL interpreter is about 400 LOC and available as an F# Snippet.

Finite State Machine in SNOBOL

Armed with a basic knowledge of SNOBOL, I could now answer the question, is the implementation even smaller in SNOBOL.

The answer is a resounding yes, and here’s the 34 lines of SNOBOL code that proves it:


Disclaimer: unlike the FParsec version there’s no error handling/error messages and the FSM must be layed out in a specific format.


The SNOBOL finite state machine parser, like the FParsec based parser, fits on a page and is an order of magnitude shorter than the broadly equivalent clean Java implementation written by Uncle Bob Martin that aimed to demystify compiler writing.

Will I be switching from FParsec to SNOBOL for parsing? Probably not, FParsec is at least as expressive, provides pretty good error messages for free and runs on the CLR.

Special thanks to Uncle Bob Martin for the SNOBOL tip Smile