Today I wanted to look at an approach for producing aggregate data from multiple measurements over a source. I’m learning Kotlin at the moment so I’ll use that for the examples in this post, but we can apply the same idea to pretty much any language (I’ve used similar approaches in F#, and it would work with C# albeit with a bit more code noise).
In which I ramble on about how my thoughts on pattern matching have changed over the years.
When I first came across the terms "currying" and "partial application" I was a bit confused about the difference. Here is my attempt at an explanation1. I’m not 100% confident of my understanding, so please point out any inconsistencies – I’m happy to be corrected :).
C and C-style languages like C++, Java, and C# tend to have method types written like this:
Other typed languages and programming papers use a notation more like this:
I found it took a bit of getting used to, but I now much prefer to read and write this style. I think it is worth becoming familiar with, as it is used in quite a few languages1 and in all the programming papers I’ve seen. So here’s a quick guide on how to read this style of type annotation.
I really enjoy trying to understand how and why things like work, but for this post I’m going to try to skip all that wonderful stuff and instead give a practical outline of how to use a very useful pattern arising from applicative functors.
I’ve found this pattern incredibly useful in F#, Swift and Haskell. The examples here are in F#, but as far as I can tell we can use it anywhere that has generic types and higher-order functions.
Today I updated a library version in a project, which changed the path from
packages/FSharpFormatting.CommandTool-2.9.1. We’d also taken our own copies of some templates in the package, and I wanted to check if there were any differences between
-2.9.1\templates that I should port across.
Rather than my usual fumbling about (check out both, copy, diff) I thought I’d try to learn the necessary Git incantation to compare the paths. And then blog it, so that when I forget I’ll have a quick reference handy for next time. :)
Today I was speaking with a colleague about some F#, and he pointed out a few gotchas with F# type signatures, especially if you’ve spent some time with Haskell (and not OCaml or other ML-ish language).
F# gave me the following error when working with some C# code:
error FS0729: This field is not a literal and cannot be used in a pattern
I’m not entirely sure it’s a good idea, but I managed to work around this using a partial active pattern.