# New features and improvements in Deedle v1.0

As Howard Mansell already announced on the BlueMountain Tech blog,
we have officially released the "1.0" version of Deedle. In case you have not
heard of Deedle yet, it is a .NET library for interactive data analysis and
exploration. Deedle works great with both C# and F#. It provides two main data
structures: *series* for working with data and time series and *frame* for working
with collections of series (think CSV files, data tables etc.)

The great thing about Deedle is that it has been becoming a foundational library that makes it possible to integrate a wide range of diverse data-science components. For example, the R type provider works well with Deedle and so does F# Charting. We've been also working on integrating all of these into a single package called FsLab, but more about that next time!

In this blog post, I'll have a quick look at a couple of new features in Deedle (and corresponding R type provider release). Howard's announcement has a more detailed list, but I just want to give a couple of examples and briefly comment on performance improvemens we did.

# Welcome fsharpWorks & F# events

If you are following me or the #fsharp hashtag on Twitter, you might have already come across a link to fsharpWorks or one of the upcoming F# events organized by fsharpWorks. So, what is fsharpWorks and what are we planning for you?

# Stateful computations in F# with update monads

Most discussions about monads, even in F#, start by looking at the well-known standard
monads for handling state from Haskell. The *reader* monad gives us a way to propagate
some read-only state, the *writer* monad makes it possible to (imperatively) produce
values such as logs and the *state* monad encapsulates state that can be read and changed.

These are no doubt useful in Haskell, but I never found them as important for F#.
The first reason is that F# supports state and mutation and often it is just easier
to use a mutable state. The second reason is that you have to implement three
different computation builders for them. This does not fit very well with the F# style
where you need to name the computation explicitly, e.g. by writing `async { ... }`

(See also my recent blog about the F# Computation Zoo paper).

When visiting the Tallinn university in December (thanks to James Chapman, Juhan Ernits
& Tarmo Uustalu for hosting me!), I discovered the work on *update monads* by Danel Ahman
and Tarmo Uustalu on update monads, which elegantly unifies *reader*, *writer* and
*state* monads using a single abstraction.

In this article, I implement the idea of *update monads* in F#. Update monads are
parameterized by *acts* that capture the operations that can be done on the state.
This means that we can define just a single computation expression `update { ... }`

and use it for writing computations of all three aforementioned kinds.

# What can programming language research learn from the philosophy of science?

As someone doing programming language research, I find it really interesting to think
about *how* programming language research is done, how it has been done in the past
and how it *should* be done. This kind of questions are usually asked by philosophy
of science, but only a few people have discussed this in the context of computing
(or even programming languages).

So, my starting point was to look at the classic works in the general philosophy of science and see which of these could tell us something about programming languages.

I wrote an article about some of these ideas and presented it last week at the second symposium on History and Philosophy of Programming. For me, it was amazing to talk with interesting people working on so many great related ideas! Anyway, now that the paper has been published and I did a talk, I should also share it on my blog:

- What can Programming Language Research Learn from the Philosophy of Science?
- Fairly minimalistic slides from my talk at the symposium

One feedback that I got when I submitted the paper to Onward! Essays last year was that the paper uses a lot of philosophy of science terminology. This was partly the point of the paper, but the feedback inspired me to write a more readable overview in a form of blog post. So, if you want to get a quick peek at some of the ideas, you can also read this short blog (and then perhaps go back to the paper)!

# BREAKING: Open-source C# 6.0 released

At last, the long wait is fianlly over! After 4 years of waiting, the fully managed implementation of the C# compiler [codenamed "Roslyn"][roslyn] has been finally released. In the recent months, "Roslyn" has been slowly turning into [vaporware][vaporware], but thanks to the recent breakthrough, the team made an enormous progress over the last two months and even implemented a number of new C# 6.0 features.

The C# 6.0 compiler, together with the full source code has been released today!

UPDATE:In case you are reading this article later than on the day when it was published, let me just point out that this was released on 1 April 2014. Just to avoid any disappoinments. Have fun ;-).

# Solving fun puzzles with F#

Do you need to convince your friends & family that programming can be fun? For the last Christmas, I got a puzzle as a gift. It is a number of small cubes, joined together, that can be rotated and folded to form a bigger (4x4x4) cube.

We spent the last few days of the year with family and a couple of friends and I left the puzzle on the table. Every time I walked around, someone was playing with it without much success. In the end, I said that if noone solves it until 31 December, I'll write a program to do it. Which I did between 7 PM and 8 PM and, voilà, here is what I got...

So, how do you solve a puzzle in about 1 hour on New Year's eve?

# Advent Art: Generating Hokusai paintings

For the last few years, the Japanese F# community has been running the F# Advent Calendar (2010, 2011, 2012). Each advent day, one person writes an article about something interesting in F#. I have been following the advent calendar last year on Twitter and when the planning started for this year, I offered to write an article too. You might have noticed that I posted a Japanse version of the article in December as part of the advent calendar 2013.

A number of people helped to make this happen - @igeta arranged everything and helped with reviewing, @yukitos translated the article and @gab_km reviewed the translation. Thanks!

But what should I write about? It would be nice to look at some of the F# open-source libraries and projects that have been developing over the last year in the F# community. At the same time, can I relate the topic of the article to Japan? After some thinking, I came up with the following plan:

First, we'll use the F# Data library and the Freebase to learn something about Japanese art. I should add that thanks to @yukitos the library now also has a documentation in Japanese.

Then we'll pick one art work and try to recreate it in F#. Given my artistic skills, this part will definitely fail, but we can try :-).

Finally, we'll use the FunScript project to turn our F# code into JavaScript, so that we can run it as a pure HTML web application that also works on mobile phones and other devices.

# Coeffects: The next big programming challenge

Many advances in programming language design are driven by some practical motivations.
Sometimes, the practical motivations are easy to see - for example, when they come from
some external change such as the rise of multi-core processors. Sometimes, discovering
the practical motivations is a tricky task - perhaps because everyone is used to a
certain way of doing things that we do not even *see* how poor our current solution is.

The following two examples are related to the work done in F# (because this is what I'm the most familiar with), but you can surely find similar examples in other languages:

**Multi-core**is an easy to see challenge caused by an external development. It led to the popularity of*immutable*data structures (and functional programming, in general) and it was also partly motivation for asynchronous workflows.**Data access**is a more subtle challenge. Technologies like LINQ make it significantly easier, but it was not easy to see that inline SQL was a poor solution. This is even more the case for F#*type providers*. You will not realize how poor the established data access story is until you*see*something like the WorldBank and R provider or CSV type provider.

I believe that the next important practical challenge for programming language designers
is of the kind that is not easy to see - because we are so used to doing things in
certain ways that we cannot see how poor they are. The problem is designing languages
that are better at working with (and understanding) the *context* in which programs are
executed.

# Advent Art：北斎の絵を生成する

ここ数年、日本のF# コミュニティは「F# Advent Calendar」というイベントを開催しています (2010年、 2011年、 2012年、 そして 今年)。 これはadvent dayごとに1人ずつ、F#に関連した何かしら興味深い記事を作成するというものです。 私は去年からTwitterでadvent calendarをチェックしていて、 今年からは私も参加しようと思い、記事を書きたいと申し出ました。 そうしたところ、数名の方からの協力を得ることができました。 @igeta には参加手続きの諸々とレビューを、 @yukitos にはこの記事の翻訳を、そして @gab_km には翻訳のレビューをしていただきました。 ありがとう！

けれども何についての記事を書くのがよいのでしょう？ 過去一年にわたって、F#コミュニティで開発されているF#のオープンソースライブラリやプロジェクトを いくつか紹介できるような記事がよさそうです。 それと同時に、日本に関連のあるトピックが何かないものでしょうか？ 少し考えてみたところ、以下のようなプランを思いつきました：

まず、日本の絵画について学ぶために F# Data ライブラリと Freebase を組み合わせて使う。 このライブラリにはいまや 日本語ドキュメント があり、作成してくれた @yukitos に感謝しています。

そして絵画作品を1つ選択して、F#でその作品を再生成する。 私の絵画スキルでは到底無理なのですが、試してみることはできます :-)

最後に、 FunScriptプロジェクト を使って F#コードをJavaScriptに変換します。 そうすると純粋なHTML Webアプリケーションとして実行できるようになり、 携帯電話やその他のデバイスでも動作するようになります。

# The F# Computation Expression Zoo (PADL'14)

F# computation expressions are the
syntactic language mechanism that is used by features like sequence expressions and asynchronous
workflows. The aim of F# computation expressions is to provide a *single* syntactic mechanism
that provides convenient notation for writing a wide range of computations.

The syntactic mechanisms that are unified by computation expressions include Haskell `do`

notation and list comprehensions, C# iterators, asynchronous methods and LINQ queries,
Scala `for`

comprehensions and Python generators to name just a few.

Some time ago, I started working on an academic article to explain what makes computation expressions unique - and I think there is quite a few interesting aspects. Sadly, this is often not very well explained and so the general preception is more like this...

# Building great open-source libraries

The hard part about successful open-source development is not putting the first
version of your source code on GitHub. The hard part is what comes next. First
of all, there are *community aspects* - making sure that the project fits well with
other work in the area, engaging the community and contributors, planing future
directions for the project and so on. Secondly, there is an *infrastructural side* -
making sure that there is a package (on NuGet in the F# world),
easy to run and useful tests and also up-to-date documentation and tutorials.

In this article, I want to talk about the *infrastructural side*, which is
easier of the two, but nevertheless, difficult to get right!
Fortunately, the F# community made an amazing progress in this direction, so let's
have a look at some of the tools that make this possible...

# How many tuple types are there in C#?

In a recent StackOverflow question
the poster asked about the difference between *tupled* and *curried* form of a function in F#.
In F#, you can use pattern matching to easily define a function that takes a tuple as an argument.
For example, the poster's function was a simple calculation that multiplies the number
of units sold *n* by the price *p*:

1: let salesTuple (price, count) = price * (float count)

The function takes a single argument of type `Tuple<float, int>`

(or, using the nicer F# notation
`float * int`

) and immediately decomposes it into two variables, `price`

and `count`

. The other
alternative is to write a function in the *curried* form:

1: let salesCurried price count = price * (float count)

Here, we get a function of type `float -> int -> float`

. Usually, you can read this just as a
function that takes `float`

and `int`

and returns `float`

. However, you can also use *partial
function application* and call the function with just a single argument - if the price of
an apple is $1.20, we can write `salesCurried 1.20`

to get a *new* function that takes just
`int`

and gives us the price of specified number of apples. The poster's question was:

So when I want to implement a function that would have taken

n > 1arguments, should I for example always use a curried function in F# (...)? Or should I take the simple route and use regular function with an n-tuple and curry later on if necessary?

You can see my answer on StackOverflow. The point of this short introduction was that the question inspired me to think about how the world looks from the C# perspective...

Full name: Tuples-in-csharp_.salesTuple

val float : value:'T -> float (requires member op_Explicit)

Full name: Microsoft.FSharp.Core.Operators.float

--------------------

type float = System.Double

Full name: Microsoft.FSharp.Core.float

--------------------

type float<'Measure> = float

Full name: Microsoft.FSharp.Core.float<_>

Full name: Tuples-in-csharp_.salesCurried

# Hello New York. Learn some F#!

Exactly two weeks ago, I started a three month internship at BlueMountain Capital in New York. They have a technical blog and should be well known to the F# community thanks to the R type provider which was written by Howard Mansell (@hmansell). I'll have the pleasure of working with Howard on some more open source data-science related tools for F# (and C#). I'll write more about these when we have something to share, but if you want to contribute and help us, join the Data and Machine Learning working group at F# Foundation.

Aside from my work, I'm also happy to get involved with the great F# community in New York!
We already have some events planned - **Progressive F# Tutorials** and **FastTrack to F#** are
scheduled for September 16.-19. so you can become an F# guru in 4 days :-). But I'm also happy
to have a chat with anyone interested in F# and perhaps do a lunch time talk, if you need to
convince your colleagues or boss that F# is a good choice.

# Update on the F# Deep Dives book

It has been some time since I last wrote about F# Deep Dives - a new project that I'm working on together with Manning, Phil Trelford and a number of F# experts, so I'd like to write a quick update. In summary, working on a book with more than 10 co-authors is more difficult than one would think (and 10 people cannot write a book in 1/10 of the time :-)), but now that the holidays are almost over, you can expect more frequent updates again!

First of all, I shoud mention that you can buy the Early Access preview of the book from Manning and there is already one in advance review of the book from Ted Neward (thanks!) who says:

As of this writing, the early-access [...] version had only Chapters 3 and Chapter 11, but the other topics [...] are juicy and meaty. [T]he prose from the MEAP edition is pretty easy to read already, despite the fact that it's early-access material. In particular, the Markdown parser they implement in chapter 3 is a great example of a non-trivial language parser, which is not an easy task (...).

As I mentioned, the book is unique in that it is not written just by me and Phil - each chapter is written by a real-world F# expert and many of them use F# in production. The disadvantage is that they are all busy people, but we have close to half of the planned chapters available already...

# Power of mathematics: Reasoning about functional types

One of the most amazing aspects of mathematics is that it applies to such a wide range of areas. The same mathematical rules can be applied to completely different objects (say, forces in physics or markets in economics) and they work exactly the same way.

In this article, we'll look at one such fascinating use of mathematics - we'll use elementary school algebra to reason about functional data types.

In functional programming, the best way to start solving a problem is to think about the data types that are needed to represent the data that you will be working with. This gives you a simple starting point and a great tool to communicate and develop your ideas. I call this approach Type-First Development and I wrote about it earlier, so I won't repeat that here.

The two most elementary types in functional languages are *tuples* (also called pairs
or product types) and *discriminated unions* (also called algebraic data types, case
classes or sum types). It turns out that these two types are closely related to
*multiplication* and *addition* in algebra...