Another C# example. This article is a continuation of an earlier post about refactoring a piece of imperative code to a functional architecture. It all started with a Stack Overflow question, but read the previous article, and you'll be up to speed. Imperative outset # To begin, consider this mostly imperative code snippet: var storedItems = new List<ShoppingListItem>(); var failedItems = new List<ShoppingListItem>(); var state = (storedItems, failedItems, hasError: false); foreach (var item in itemsToUpdate) { OneOf<ShoppingListItem, NotFound, Error> updateResult = awa ..read more

Package a constant value, but make it look like a functor. An article for object-oriented programmers. This article is an instalment in an article series about functors. In previous articles, you've learned about useful functors such as Maybe and Either. You've also seen at least one less-than useful functor: The Identity functor. In this article, you'll learn about another (practically) useless functor called Const. You can skip this article if you want. Like Identity, the Const functor may not be that useful, but it nonetheless exists. You'll probably not need it for actual programming task ..read more

The answer is traverse. It's always traverse. I recently came across a Stack Overflow question about collecting and handling sum types (AKA discriminated unions or, in this case, result types). While the question was tagged functional-programming, the overall structure of the code was so imperative, with so much interleaved I/O, that it hardly qualified as functional architecture. Instead, I gave an answer which involved a minimal change to the code. Subsequently, the original poster asked to see a more functional version of the code. That's a bit too large a task for a Stack Overflow answer ..read more

How to convert a list of tasks into an asynchronous list, and similar problems. This article is part of a series of articles about functor relationships. In a previous article you learned about natural transformations, and then how functors compose. You can skip several of them if you like, but you might find the one about functor compositions relevant. Still, this article can be read independently of the rest of the series. You can go a long way with just a single functor or monad. Consider how useful C#'s LINQ API is, or similar kinds of APIs in other languages - typically map and flatMap m ..read more

Are Haskell IDE plugins now good enough that you don't need explicit type annotations? More than three years ago, I published a small article series to document that I'd changed my mind on various small practices. Belatedly, here comes a fourth article, which, frankly, is a cousin rather than a sibling. Still, it fits the overall theme well enough to become another instalment in the series. Here, I consider using fewer Haskell type annotations, following a practice that I've always followed in F#. To be honest, though, it's not that I've already applied the following practice for a long time ..read more

A functor nested within another functor forms a functor. With examples in C# and another language. This article is part of a series of articles about functor relationships. In this one you'll learn about a universal composition of functors. In short, if you have one functor nested within another functor, then this composition itself gives rise to a functor. Together with other articles in this series, this result can help you answer questions such as: Does this data structure form a functor? Since functors tend to be quite common, and since they're useful enough that many programming language ..read more

A translation of the kata, and my first attempt at it. In early 2013 Richard Dalton published an article about legacy code katas. The idea is to present a piece of 'legacy code' that you have to somehow refactor or improve. Of course, in order to make the exercise manageable, it's necessary to reduce it to some essence of what we might regard as legacy code. It'll only be one aspect of true legacy code. For the legacy Security Manager exercise, the main problem is that the code is difficult to unit test. The original kata presents the 'legacy code' in C#, which may exclude programmers who are ..read more

A choice of two or more functors gives rise to a functor. An article for object-oriented programmers. This article is part of a series of articles about functor relationships. In this one you'll learn about a universal composition of functors. In short, if you have a sum type of functors, that data structure itself gives rise to a functor. Together with other articles in this series, this result can help you answer questions such as: Does this data structure form a functor? Since functors tend to be quite common, and since they're useful enough that many programming languages have special sup ..read more

A puzzle kata, and a possible solution. When I was a boy I had a nine-piece puzzle that I'd been gifted by the Swizz branch of my family. It's called Das verflixte Hunde-Spiel, which means something like the confounded dog game in English. And while a puzzle with nine pieces doesn't sound like much, it is, in fact, incredibly difficult. It's just a specific incarnation of a kind of game that you've almost certainly encountered, too. There are nine tiles, each with two dog heads and two dog ends. A dog may be coloured in one of four different patterns. The object of the game is to lay out the ..read more

Another functional model of a file system, with code examples in C#. This article is part of a series about Zippers. In this one, I port the FSZipper data structure from the Learn You a Haskell for Great Good! article Zippers. A word of warning: I'm assuming that you're familiar with the contents of that article, so I'll skip the pedagogical explanations; I can hardly do it better that it's done there. Additionally, I'll make heavy use of certain standard constructs to port Haskell code, most notably Church encoding to model sum types in languages that don't natively have them. Such as C#. In ..read more