I'd been out of Liverpool for 3 years or so, and I completely missed GeekUp: a loosely
affiliated, grassroots tech meetup society in the North West. The Liverpool branch is
pretty active, and linked with various other groups, such as the
DotNet user group,
where Chris Alcock gave a very interesting
talk on F#.

Not sure what the Dot Net programmers made of it, there were some questions afterwards
amounting to "What's the point? Are academics going to use it?" :-) Which I thought
was amusing as I was looking at it from the perspective of a Haskell newbie, thinking
a) that's cool, b) it's simpler than Haskell, c) it plugs into the .Net libraries and
development environment, and had concluded that it could (possibly) become a massive hit
in real-world programming too…

Some notes, mainly comparisons with Haskell:

• The #light pragma adds syntactic sugar, very much like the
  Haskell do notation. (No need for open/close/statement delimiters,
  whitespace significant, skip in off let statements)
• The REPL is multiline by default (dons on #haskell noted that ghci
  supports this with :{
• Functions aren't recursive by default and have to be introduced as such (let rec factorial = ...)
• Lists aren't lazy, but there's a separate datatype called Seq which is.
• You can use yield in a function to define lazy sequences.
• Like Ocaml, F# supports mutable data, though the default is pure data.
• It also supports reference types – I'm not sure I understand what these
  are for in a functional programming language, or if they're just for updating,
  then how they're different from plain old mutable data. The example Chris gave
  was the classic closure example of a counter function.
• 
  The examples he made of pipelining with |> and >>
  looked very much Haskellish monads (especially in a #light style
  block). I quickly leafed through Chris's copy of
  till I found the
  section on monads. They're called "Workflows", because that's less scary than
  Monads. They're also largely transparent, which on one hand is nice, as
  there's none of the painful and ugly "lifting" of values to the appropriate
  monad. (On the other, it means that you can't easily separate action and
  non-action code).
• This of course means that you don't get some of the benefits of FP's
  purity. Martin Owen, who is keen
  on Erlang and its capacity for massively scalable, high performance networking,
  also pointed out that allowing mutability means that you can't guarantee that
  the application is threadsafe, and is the wrong default as we're coming up against
  multicore programming.

All in all, it was a very interesting talk, and I'm looking forward to playing
with F#. I apt-got Mono, and
promptly failed to install F# on it, as the provided install.sh script whined about
something to do with gac and aot. Ah well, perhaps that's a good
excuse to boot up into Windows…