Forem: Paweł Stadnicki

What F# Knows About Functors and What Comes Next

Paweł Stadnicki — Fri, 26 Dec 2025 20:29:43 +0000

This post is a short, opinionated reflection on one thing that feels most notably missing in F# today. It provides brief background, references recent discussions on why this gap exists, and ends with a teaser of a possible solution that we will shortly have in our arsenal.

When F# Alone Is Not Enough

Let’s look at something we already have—even if we don’t quite treat it as a first-class citizen. Let's look without precise category-theory definitions, just an intuitive picture.

You may have heard of a Functor

Functor is a great name for a dog.
In programming, you can leave one alone for days
and it will still behave exactly the same, obeying all the laws.

As an F# developer, if you want to play with a Functor, you usually have to name your dog yourself (or your cat — but that would make the metaphor silly).

To be precise: such a pet does exist in F#. But it remains unnamed — unless you use the FSharpPlus library as a kind of dog collar. And while that helps, it’s still not quite the same.

The behavior is present; the abstraction is not.

In F#, the idea of a functor survives without the name — an example of how far the language goes, and where it deliberately stops.

This is not a complaint. It’s a reflection on growth — of the language, and of its ecosystem.

There are things that are simply not expressible in F# today.
The most important of these is the ability to abstract over type constructors themselves.

Full HKT support lets you name, pass around, store, compose, and reason about abstractions—not just use them implicitly through functions.

In F#, we can rely on functorial behavior (map on Option, List, Async, etc.), but we cannot name it, quantify over it, or require it in our own APIs.

Changing a language at its core—for example, by redesigning generics—is an extremely disruptive, breaking change. Scala is a notable example here: because it was designed from the ground up to support HKTs, it was able to implement type classes through its implicits mechanism.
F#, by contrast, is built on .NET’s reified generics, which prioritize runtime performance and cross-language compatibility, but lack the native infrastructure to abstract over containers (F[T]) without complex workarounds.

Don Syme, in his well-known position on type classes, writes:

“I don’t want F# to be the kind of language where the most empowered person in the Discord chat is the person who knows the most category theory or abstract algebra.”

(Please read the full article; this excerpt is intentionally selective and used here only to frame the discussion.)

That position is understandable — and arguably the right one for a mainstream language.

And what about creating a new language altogether?

As Anders Hejlsberg, the creator of C# and TypeScript, recently noted:

Introducing new programming languages in the AI era is inherently disadvantaged: the “best” language for AI is the one it has seen the most.

So, to tackle today's complexities, maybe indeed we should revisit Category Theory?

Yet another CT geek, huh? I'm still learning, but the past few months—after years of trying and abandoning the subject—have brought me to a realization: you either know Category Theory well enough to use it confidently, or you don't use it at all.

A DSL with real HKT support would allows us to define behavior once and lift it across structure. It lets us reason about effects without committing to execution, and about context without sequencing. That’s why functors—and, naturally, comonads—are often the right place to start when designing complex effect systems. They operate at a more fundamental layer than monads: the layer where the meaning of context is defined, before effects are sequenced.

With HKTs, a lot of CT will become more obvious. Almost boring, but surprisingly enjoyable.

And that’s the point.

So Where Does This Leave Us ?

What does not emerge in the open often continues to grow elsewhere.

In 2026, we’ll be able to use more ideas from Category Theory in practice—not by escaping language constraints, but by working with them deliberately. This will happen through a DSL/language being built at BLP: written in F# and extensible with F#.

I have the privilege of being the dumbest person in that room—and of getting to play with these ideas early.

This post is not a reveal of that DSL yet, but simply a short opening note. The concrete parts, with proper credit to authors will be discussed starting in January.

I'm alone in this opinion ?

This year’s Advent of F# calendar reflects a noticeable shift. The majority of contributions focus on domain modeling, types, language tooling (LSPs), and even programming language design, rather than MCP-related topics. At the same time, Tomas Petricek—the long-time advocate of effect systems—continues to deliver excellent lessons on building small, well-structured systems in F#. There is also a promising book coming next year, The Book of Functions, which fits perfectly into this broader reflection.

Flying with F#

Paweł Stadnicki — Sat, 09 Dec 2023 15:54:33 +0000

This blog post is a part of the awesome F# Advent Calendar in English organized by Sergey Tihon, an annual collection of more than 30 posts, that could form a book "F# in Practice" by the community.

The source code for the presented experiments can be found here.

The topic

How far are F# devs from creating sth cool?

Sometimes it is just a single JS binding.

In my spare time, I enjoy working on Proof of Concept (POC) projects.

I select something that I find interesting, quickly develop a Proof of Concept, and then move on to the next one.

I believe that by creating around 20 POCs, I can eventually build an interesting product from a few of them. It's a reverse approach to applying technology. Normally, you start with a specific need that technology should address, but in my case, I begin with the technology itself.

Certainly, this approach may not be the most conventional or lucrative one, but I find it rewarding nonetheless.

This time I present how to combine F# with Google 3D Photorealistic tiles.

I demonstrate the seamless integration of key elements. With each animation frame, you can harness values like location, bearing, zoom, and pitch, and transform these into captivating experiences - from rotating around a locale to following a route, or even simulating a drone flight. Elevate your website with a map that's not just dynamic but truly alive!

Start by obtaining your own API key for the 3D tiles. While this product has transitioned from a preview to a paid service, you can receive a generous $200 monthly credit, giving you ample freedom to explore its features. Beyond this, the cost is $6 per 1,000 'root requests'. For high-traffic applications, this means $6,000 for every million views. It's important to factor this into your planning. For more details, be sure to review the documentation thoroughly.

Implementation

The best thing about tiles in general is that all you need is to host them and move around with some sort of engine. Obviously, all of these engines are inherently connected to JavaScript. Fortunately, we have Fable, so the only challenge is to find a library, for each we can write binding easily.

I noticed on Twitter that Foursquare Studio has the option to add these tiles very easily:

I knew that this tool is built with DeckGL, so I checked their docs and ... there is a very simple example (https://deck.gl/examples/google-3d-tiles).

Translation of this example to Fable looks like (one of the possible approaches):

And the actual binding:

DeckGL just expects view state object with certain values to be used in the projection (and animations):

As we are using React, all we have to do is update this object with the setState or Elmish hook. In my experiments, I'm using the latter.

The PoC has a simple dashboard, you can check the implementation to see how appropriate values are updated with Elmish style:

I also provided 4 simple animations:

move to a location:

rotate

Implementation of the rotation move is pretty straightforward:

follow the path

Implementation is slightly more complicated:

You can notice a pattern that in order to create new animation you only have to implement a function and describe how the view (state) changes with time:

Calling such animations in Elmish requires returning it as a Cmd of effect:

Other interesting animations can come from the keyboard events:

Check the implementation if you are interested in how I played to emulate a drone flight. Make note that it is a very naive and not complete approach. Actually, this is not the way it should be done: instead, some sort of DeckGL view should be created. However, I had fun with it and could completely control the animation.

Few more suggestions:

to get the user location (from the browser):

to measure distances and convert between our parameters I'm using TurfJS, for which binding is even more trivial:

Summary:
This is a brief description of my 3D tiles endeavor. We can go pretty far with it. If you are interested in moving it further or using it in your project, please reach out to me via Twitter.

Distance Type Provider

Paweł Stadnicki — Fri, 23 Dec 2022 22:50:34 +0000

I'm presenting my Distance Type Provider: a little bit different, literacy-close type provider, created for interactive, notebook-driven geospatial explorations.

If you threaten the geospatial domain as far from your interest, I encourage you to read the post even more, as I'm using tangible, life inspired examples.

Distance Type Provider plays a crucial role in my other, not yet released endeavor Florence, but can be used alone.

In short, DTP helps to find distances and travel times for different movement profiles just by typing:

You can find some of the examples I present here.

Type Providers

Type Providers have many applications and are a fabulous concept on their own. Almost any F# developer had intrinsic desire to create one at some point!

They are especially useful in data explorations: you get a local or remote data source and query it.

Most of the existing type providers have a generic purpose to traverse through well established schemas: json, swagger. Other serve DSL purpose like Regex. World Bank type provider is instead one that is very close to the literate programming. It collects development indicators and other data about countries in the world:

Literate programming is about writing code, that is meant to be clear to a human being, not a developer itself. In data explorations, any burden distracts and we should document what we already know. Literate code communicates data as information. It is very useful.

Distance Type Provider

If you follow me on Twitter, you know that I'm interested in smart city and open data domains. They in turn are strictly connected with geospatial, and geospatial is all about distances.

You may ask:

Wait! Distance is something you measure, it is a value or variable but not a type! Ok, it can be int or float (or unit of measure) but it already exists...

It is all about data literacy. The goal is to not only provide a distance itself, but ask about it in plain English.

Let's start with an example, which describes our life without such a provider.

Ordinary code

Assuming we have a set of places (with names and positions):
how can we calculate distances between some wanted places ?

Every developer wrote similar code hundreds of times and it is very easy to follow, even for newbies and people outside IT.
However, we need to filter out wanted entities first. If we want to compare many of them, the code will consist mostly of middle steps everyone has to read (and potentially, likely be distracted from the program goal). Also, with more and more data, data discoverability shrinks.

So how we could write code with data literacy?
In other words, how we would transform the previous code to a question in English ?

With Distance Type Provider you can write code exactly like above.

Geojson everywhere

To make the provider as generic as possible, it expects a geosjon as an input.
If we look at F1 dataset, that contains F1 tracks, we can find some properties that determine these tracks:

The default geojson property that provider expects is "name", so if we run provider without additional parameters, we can check distances based on track names:

If we want to use other attribute name, we should pass it as a static parameter:

What about two different data sources ?

MyLife geojson is very interesting, as you can define it once and use it in many municipal analyses.

Florence even comes with special editor based on Mapbox autofill that you can use directly from the notebooks:

and/or continue data analyses in the very next cell:

With such a life space data ready for our disposal, we can rank city places with life-inspired function:

Spatial distance vs actual distance

The easiest way to measure the distance between 2 points is to provide spatial distance, a straight line length. It can be calculated with this formula. Although it is not 100% accurate for larger distances (
due to possible differences in height above sea level and the fact that the Earth is not perfectly round ) it is fair enough for most analysis.

So spatial distance is the default one.

But there are situations when we need a distance between 2 or more points, that is measured through the exact road or path. Moreover, the road will be different depending on the means of transport used: car, bike, bus. We can always decide to just walk.

And all of these can return different values on different hours due to the current traffic level.

Fortunately, there are data providers that do that for almost any area in the World.

Distance Type Provider leverages Mapbox for this purpose.
Despite the fact Mapbox offers generous free plans, the provider user must use his own token.

In return you get 3 new profiles: driving, cycling and walking:

That is nice! What about checking more data at once? Not a problem at all, you can use any place from the geojson combined with any other, even at hoc location:

Just in case you haven't noticed it:

Mapbox direction-matrix API return also expected duration of the travel. That is a nice bonus!

What next

To be honest, I added the Mapbox support just 2 days ago so it is all very fresh. The provider itself is still experimental but will evolve ratehr rapidly, / I definately want to add many more capabilities of the Mapbox API.

I hope it will serve some purpose outside of my own experiments!
Stay tuned for more geospatial stuff related to F#.

Geospatial is a function of your life

Paweł Stadnicki — Tue, 06 Dec 2022 10:40:38 +0000

In this post I present Florence,
a low-code geospatial library for everyone that ranks city places with (life-inspired) functions.

Florence heavily laverages .NET Interactive/Polyglot Notebooks runtime to hide and execute code behind the scene (including breaking some language constraints).

I use open data for Zurich from https://data.stadt-zuerich.ch/, but you can use any geojson data, including imaginary Worlds.

Florence is still an experimental library, alpha release is due 24th Dec.

Is geospatial hard and boring?

Geospatial isn't hard, it is rather not accessible for a novice.

You may think that certain tools are expensive, reserved for municipal departments, and that advanced programming is required (in languages you don't necessarily like).

You can also treat this domain as (a little bit) boring.

Geospatial might be hard and boring
...unless you are not aware that you are doing geospatial.

Surprisingly a lot of geospatial analysis boils down to the question "what is the best place for/to ... (anything)?".

Also surprisingly to answer this very generic question, we can write a very simple function!

A function that takes place (or facility) and returns its value.

Such a function can be run against all well-known city districts, blocks, or custom areas.

How to get this data? "You said your library is for everyone but I don't have data-related digital skills...".

Correct, with Florence you don't care about data retrieval and types, you have it on hand. Just think about having fun(ction).

Florence: take a quick look

Florence requires at least one data file to be located in a geojson folder of your VS Code workspace. Once you load the Florence package, your files are loaded and you have strongly-type access.

Notebook's author can share all geojson files along with the notebook. However I created a special geojson.cloud, so you can explore and download necessary files directly from the F# cell:

Under the cover it is some sort of a simplified Azure Storage Type Provider but with a capability to share cloud data without sharing the cloud access keys.

It is very handy, discoverable, and useful especially for bigger datasets, like addresses. Every dataset has necessary license data on folder or file level:

The function of your life

To do your analysis, you need to write just one function, like the function of your life. Such an activity is not just for fun, it can have many real applications. Imagine all residents are able to write it among plain data querying and joining: we can get exhaustive, the most powerful municipal platform possible.

As everything that Florence expects is a geojson, your life also must be defined in geojson file. Don't be scared, there will be a nice, graphical way to define your life space directly in the notebook:

For the time being, as most of us do not live in Zurich, we can ... rand our lifespace.

Once the cell is executed, quite a lot of magic happens under the cover. You put names of all your important places in a list, their locations are randed, and the special type called MyCityLife is created. When you feed the type with some location, you will get distances to your important places via their names.

The clue here is that those places can be anything, any citizen can name it differently.

Having your city life space type on your disposal, you can write the proper analytical function:

This function will be different for many people, even for the same person it can change overtime (there are times when we don't necessarily need our parents-in-law to be close, but it will dramatically change when children arrive).

You can run your function against the same or any other geospatial file containing city places:

Distance Type Provider

MyCityType used in the calculation is in fact a type created by a special F# Type Provider. It gets all geojson feature's properties and calculates the spatial distance to another provided location.

There are more applications for this than the presented function of life. You can get the distance between certain places similarly to asking plain questions (example for F1 fans, all you need is a single geojson with F1 tracks):

You can also measure a trip:

Other applications

In this post, I did focus on applying the function of life for geospatial purposes.
But this is only the tip of the iceberg of what you can do with Florence. The main capability is to include more data in the calculation. What if the best place should be determined based on route count of the 3 nearest stations ?

The tricky part is to join datasets in a readable, succinct manner. You can use the full F# power here. I'm pretty sure F# developers will have fun with it.

Pulumi and .NET Interactive (I)

Paweł Stadnicki — Tue, 13 Sep 2022 14:06:00 +0000

In this post, I will explain how to provision Azure Static WebApp with .NET Interactive (Visual Studio Code) and Pulumi Automation API.

In the follow-up post, I will extend the notebook to cover frequent web app dependencies like API app function, custom domains, etc.

I'm using the React preset (with plain dist), but you can easily adjust the notebook to other static websites build flavors.

You can download the full notebook here.

To run the notebook you need to have a basic knowledge of Pulumi (CLI must be installed and Pulumi Access Token set)

About IaC

Learning Infrastructure as a Code (Pulumi, Terraform, Bicep, Arm templates,...) is an investment.

As with any code, IaC is a liability that we must maintain. Also, the underlying architecture must be clear for each team member who touches it. The decision to use it is not an easy tradeoff.

Often we deploy to the cloud only pretty simple resources. It could be significantly easier to create them via portal and just ... forget. We can think about potential growth and security aspects when it happens. It is all good.

However, IaC is not only about automation (speed & robustness). It is about disaster recovery too. Let's first talk about the subject we do cover.

Azure Static Web App

Azure Static WebApp is one of the best options in regards to cost and involved operations to host a web application. It also leverages DevOps well by supporting GitHub actions.

It means that by creating a resource we also seamlessly run a workflow to deploy the code from the repository in one shot.

It is a fast process and doing it via portal requires just a few fields:

Of course, to get a more grained set up you have to add proper settings after the provisioning (custom domain, API,...)

So unless our web app is not a part of a wider solution, using the IaC may be overkill for those who need to learn it first.

Automation Provisioning = Disaster Recovery

Unfortunately despite all of these static web app benefits, I do often encounter troubles with github actions after the initial application deployment. I'm getting completely unclear messages and in order to apply new code changes (which may be critical) I have to reprovision this Azure resource.

It is not as easy as it sounds when web app is connected to API or uses networking. Deleting all dependencies may be a burden, especially if we want to keep the same namings.

In such situations, I would like to recreate it by running a program/notebook with a language I know well.

.NET Interactive & Pulumi Automation API

With .NET Interactive we can run C# (F#, Powershell, Kusto, SQL) from the notebook which makes the process nice, clean and composable with other actions that we can do earlie or later.

Obviously, Pulumi does not come with .NET Interactive, however to use it we only need to load some nuget packages

While working with Pulumi (or Terraform), I tend to write a code as I would have had many subscriptions in place for each environment (even if I only have one subscription and I start with one environment). It always pays me off later.

Pulumi enables (at least) two ways to name the resources
1) Automated
2) Manual

The first one helps with name conflicts, soft-deletion, zero-downtime deployments (to name a few) but as a side effect produces enigmatic names. It is not always only a personal decision to select proper naming (can be enforced by Enterprise Architectures or so on) however I tend to use the second option.

In order to use it clearly, all my namings are built up similar to:

Flaging environment (dev/qa/stage/demo/whatever) can also impact the resources inputs:

For Static WebApp we need GitHub credentials which can be kept in a notebook or workspace, depending on where you keep/store the notebook etc.

Note that GitHub token should has right to operate on Github workflows

You also need to configure Pulumi Automation API. It needs some information as it would have been a standard project:

Now it is finally a time for the main dish.
Lets configure Pulumi to create Web App per our needs.

Lets run the program:

In case you were only playing around , you can delete the resource by:

Summary

After reading this post you may consider using .NET Interactive & Pulumi API for your ad-hoc provisioning needs or to enable users of your (open source) project to create needed infrastructure and host a copy of the product.

Processing Open Street Map data with F# and .NET Interactive

Paweł Stadnicki — Mon, 22 Aug 2022 21:17:00 +0000

There are several reasons you may want to obtain municipal data.

You can present them nicely on your website in a form of an interactive map, or you can perform some geospatial analysis like finding distances to the closest facilities.

Or maybe you just want to play with F# language on real, tangible datasets?

In this post, I explain how to get any data from OpenStreetMap, convert it to geojson, and parse for wanted places so you can take them and have further adventures with F# and real data.

You can download the notebook here

*You still have to generate geojson file on your own as described in the post

Open Street Map / Open City Data

OpenStreetMap is an excellent source of city data that is absent or not covered enough by the open data portal maintained by city governors.
This is especially useful for small cities and villages (that don't have data portal at all) or to quickly get data that have potential commercial value.

Be aware, that in contradiction to open city data, OSM data are not complete and hence not perfect for many business scenarios. The data are most often injected by plain users, which puts the OSM data schema robustness ...at risk.

Even if you are among lucky citizens where the data portal shines (please check ~200 geojson files for Rostock (Germany): https://www.opendata-hro.de/dataset/?res_format=GeoJSON) you can still find OSM valuable and complementary to aforementioned.

Examples

I'm using data for London, as it is a huge city that still lacks some publicly available open data. Also, the data volume itself requires special steps not needed for smaller areas. I parse rivers, addresses, shops, and leisure; however, any facility for any city can be obtained in the same (or almost the same) manner.

What I do present here is zero rocket science, just grabbing data, converting to geojson, and parsing. I'm sharing it as it can be tedious for someone who never worked with geojson in C#/F#.

Yes, you can write an idiomatic functional parser, "type provider" as well, however, I'm not sure it will make working with these data more pleasant and approachable to the average programmer (taking into account OSM data schema flaws)

Getting data from Open Street Map

Pythonists have plenty of OSM (and all relevant geospatial) libraries at their disposal, there are some libraries for dotnet as well.

However, I like to work primarily with raw geojson files as it is a well-known, human-readable format so I can go through the file to understand how to process the wanted data.

Go to OSM
and you will see some map tiles:

You have at least two options to select the city that is relevant to you:

scroll accordingly to cover the wanted area and press export -> overpass API
or type wanted area name and then click 'export'.

Be aware that these options have limitations in size, you cannot download too large areas this way. For example, I'm not able to download the whole London data.

In such scenarios, you can download the appropriate datasets via plenty of pre-generated files. For London you can find it here:

https://download.geofabrik.de/europe/great-britain/england/greater-london.html

Converting to geojson

After download, we have ~1.5 GB OSM file
To convert it to geojson I'm using npm package called ... osmtogeojson. For those who are not working with nodejs on a daily basis it is very simple: just install the tool globally

https://github.com/tyrasd/osmtogeojson

and then convert

For London file I'm getting out of memory error hence need to run the program, based on the clue from the documentation:

The conversion takes ~1-2 minutes for such large file.
For smaller cities it can be simpler to download data in *.shp format and convert to geojson via mapsharper.com, https://mygeodata.cloud/, ArcGis or many, many other options.

As we have a file, we need something to process it.
In my case, it is .NET Interactive extension for Visual Studio Code.

.NET Interactive

You can now open downloaded notebook in Visual Studio Code.
The notebook (*.dib) I provide for you expect the geojson file to be in same place (otherwise please adjust the path accordingly).

The very fist notebook cell loads geojson file and parse it to get the items. There are almost 2mln of items processed in 6 seconds. Not that bad.

Now get some city goodies, starting with ...water.
But only rivers that have some name assigned.

This ...TryGetProperty.. from JSON deserializer is not perfect here, definately could be wrapped somehow but I just want here to show how things work without DSL.

Output of the code depends on extension you have installed. Unless you have some renderer extension from marketplace you will see just raw text.
My favorite one is the Unfolded Map Renderer extension created by Taras Novak, however it has been made private recently (unless you are supporter as I'm). You can still use one of his many other extensions available here:
https://marketplace.visualstudio.com/publishers/RandomFractalsInc

If you want to store the result of your filter in a separate geojson file, you can do it by
:
and host on your website, open and play with any other tool like geojson.io

You can query whatever facility you want:

... using as many functions from collection modules as you want

Random addresses

What about addresses ? Well, I rarely need to process them this way as typically municpal portals enables them or they are available via Open Addresses. Apparently London does neither of them ( I believe this is because of a private sector etc).

Addresses in OSM are (from my best knowledge) NOT a standalone object, it means they are just attributes of associated objects.
It can end up with many objects having the same address, and what is more important: they can be either points of polygons. And we most likely want to have unified shapes like point.

First, let get them with a familiar approach that additionally does some distinctions.

Is this 113k addresses a correct number of real addresses ? I don't think soo but it still is usefull dataset for experiments.

Using NetTopologySuite for geospatial analysis

We already did a lot, but in order to do more we have to introduce dedicated library/package. In dotnet it is NetTopologySuite.
You can achieve a lot from the geospatial perspective with this library, here we just want to get centroids for polygons. Additionally I'm getting rid of unwanted properties, keeping only street, number and city.

Important remark!
NetTopologySuite doesn't work nicely with .NET Interactive, it will hang forever unless you are using old interactive version.
So if you want to run the rest of cells
you have to temporary rollback to mentioned version:

There is a workaround suggested from .NET Interactive team to make it work with latest version, I will update the post as soon as I know how to apply it.

We started to process data with System.Text.Json.
NetTopologySuite has equivalent version for processing geojson called NetTopologySuite.IO.GeoJSON4STJ. However here I'm using the regular one as "STJ" doesn't work properly with my advanced processing (not covered here). Hopefully all at some point will be unified.

*Lets rand some addresses. *

Please note than when using projection library build on WebGL (like unfolded), displaying hundreds-of-thousands items is very smooth

What next

I presented how to obtain and process geojson municipal data.
Actually it should be called "preprocess" as I haven't touch any interesting processing from the user perspective. Now we could connect this with actual "domain" processing, join with other data sources and add true F# expressiveness on top of that.
But this is for another story.