Oct 6, 2024

Introduction and Context

Disclaimer

I have been increasingly frustrated with the narrative online about what’s goig with Hurricane Helene relief efforts w.r.t. civilian aviation. This is my personal experience with flying an aid mission, I do not speak for anyone else or any organization, others may have had other experiences.

Why Light Aircraft?

Helene caused bridges to collapse and many roads to be washed away. Trucks are the most efficient way to transport supplies/goods, but only if they can actually reach the destination. As roads were being cleared or alternative paths being built, light aircraft are able to fly into more remote areas and deliver supplies. The United States has the largest civilian aircraft fleet in the world, and it’s beginning to be more common to leverage this fleet after a natural disaster.

The aircraft that I fly is designed for flight into short runways/strips, and can even be used for ‘off airport’ operations, so I decided I would try and help.

Context about Flying and Air Traffic Control

In aviation there are a few different ‘flight categories’. Visual Meteorological Conditions (VMC) mean that you are able to navigate by visual references to the ground, sky, and horizon. There are ‘objective’ standards by which VMC is judged, the visbility must extend a certain distance, the cloud ceiling cannot be too high, etc. Another common category is Instrument Meteorological Conditions (IMC), which means that flight cannot be accomplished by visual references and must instead be accomplished ‘by reference to instruments’ in the cockpit.

Those are the categories as determined by the weather, there are also regulations that determine how you need to fly (distance to clouds in different airspaces, do you need to be talking to ATC, etc.). You can fly by the Visual Flight Rules (VFR) only in VMC. You can fly by the Instrument Flight Rules (IFR) in VMC or in IMC. You might choose to fly IFR in VMC for practice or because of the additional support you get from ATC, etc.

Lastly, if you’re flying by VFR you often don’t have to talk to ATC unless you want to, you’re expected to ‘see and avoid’ other aircraft. If you want to, and if they have the capacity, it can often be beneficial to be talking to them as they see the bigger picture of who is going where and can help you avoid other aircraft/warn of know weather issues/etc.

Things were so busy in Western North Carolina that unless you’re part of the relief effort, ATC didn’t have enough capacity to talk to everyone that wanted to talk to them. At one point they weren’t even able to help with IFR flights, which means that if the weather is not VMC, you can’t take off and are stuck on the ground until they have the capacity to talk to you or the weather becomes VMC.

Relief Efforts in NC

Dispatch

So I fly down there Friday morning from DC. While I was still in DC airspace I tell ATC where I’m going, they know from context that I’m heading down to help with the relief effort. ATC was overwhelmingly accommodating. Every step of the way they were helping aircraft get to where they needed to go. When I got to the airspace near the relief effort it was busier than any airspace I have ever flown in.

The organization I’m working with has a supply hub, near Charlotte, that had been spared the worst of the storm but was still near enough to the Appalachians to fly supplies in where they are needed. By this stage of the relief efforts things were fairly well-oiled.

I land at the supply hub, they only asked three bits of information:

• My tail number
• the type of aircraft
• How much cargo (weight) I can take

Because the aircraft I fly is able to land in tighter spots, the dispatcher (person figuring out who should go where) asked whether I was comfortable going to an airport that was a bit trickier, and had therefore received fewer supply runs. My co-pilot and I spent some time looking up the airport; its runway lengths, its elevation, and determined that while tricky we were comfortable with the mission.

Dispatch was trying to get supplies to where they were needed, they used this whiteboard to keep track of who needed what:

You can kinda tell from the photo above which areas were further along in their recovery. Because communications were often cut off (depended on the area), a lot of this information was relayed by the pilots returning from supply runs.

Similarly runway/weather/airport conditions were tracked as well:

Not every airport is there (mine wasn’t) because this dispatcher hadn’t yet received word (it turns out that other orgs had made supply runs there, this dispatcher just hadn’t known about that).

Volunteers had pre-weighed pallets of supplies. Depending on where you were going and how much you could carry, you’d pick a pallet to be loaded into the aircraft. Volunteers helped at each stage of this process, including loading the cargo.

At no point did anyone from the FAA or FEMA get in the way of this process (a claim being made online).

Supply Run

The tower at the supply hub was so wildly busy and they were working magic. They did a fantastic job of getting everyone off the ground in a timely manner. As one aircraft was waiting on an IFR clearance, and they had me taxi through the grass in order to depart earlier since I was flying VFR. Not really the behavior of someone trying to prevent people from helping.

On the way to my destination ATC was great again. The approach and landing went as briefed, we had to descend into a valley, which is always a bit spooky as it means there is terrain higher than you as you come in for a landing, leaving you with fewer options if things go poorly. While it was uneventful, the pre-planning was absolutely necessary as it was tricky and full of obstacles.

The folks on the ground there helped me unload the plane and had special requests for aid. They asked me to communicate those requests back to dispatch. On the way back to the supply hub I had a very close call with another aircraft¹. Normally ATC would have given me a heads up, but they were so swamped. Weather was getting worse too, which caused congestion of VFR aircraft since we all had to find visual paths around clouds and holes through layers for descent.

Unfortunately the weather prevented further supply runs to that area. Luckily (though I did not know this at the time), the roads opened up to that area later that day, which is great news.

The issues on the ground are that the infrastructure has been destroyed, communication is difficult, and the environment is changing all the time: some roads reopen, which shifts where aircraft are actually needed, etc. All of these are difficult coordination problems and there are many cooks in the kitchen; all well-meaning and all trying their best.

I want to reiterate because it’s by far the largest discrepancy between what I experienced and what I’m reading on the internet: at no point was the government ‘in my way’. It’s just a very difficult overall situation! When ATC closes off a part of airspace it’s not to prevent people from trying to help, it’s because when the weather is getting worse they have to close off airspace so that larger supply aircraft can navigate safely without risk of midair collision.

I was sad that I could not do more, and that I hadn’t gone earlier in the week. That said, it was gratifying to be able to help, even if it was a small help.

I have immense respect for those working ATC and folks doing supply runs over multiple days.

-JMCT

Mar 7, 2022

Introduction

It’s possible that Russia will disconect or be disconnected from the global internet, with some reports saying that this will occur by Friday. I am unsure how likely this is, but they have practiced this in the past. Regardless, lots of folks who depend on Russian websites and resources for their work are a reasonably concerned. This is a very rough guide to how you might be able to download those resources for your own use offline.

Disclaimer:

We’re going to skip over a lot of the why, we’re doing the things I describe below. Normally, I’d want to motivate it and ensure that you’re all empowered by understanding the tools you’re using, but there isn’t time for that today, maybe another time.

Get wget

You’ll need wget, which is a tool for ‘getting’ resources from the web.¹

Mac

If you’re on a Mac, the easiest way is to open up Terminal (use spotlight to open up the terminal) and type the following command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once that finishes, check that it worked by running the following (the dashes, (--) matter):

brew --version

If you get back something along the lines of “brew not found” then the command didn’t work. I’m sorry. You can try emailing me, but it’s going to be hard to figure out what went wrong remotely. If you got back a message saying what version you’re running, great! Run the following:

brew install wget

Once that is complete, we’re going to do a similar test to see if it worked:

wget --version

If you get something like command not found, it didn’t work. I’m sorry. Otherwise, you’ve now installed wget, which is the main tool we need. Skip to “Using wget”.

Windows

If you’re on Windows, this site seems to be the most straightforward way of getting wget running on your system. I do not have a Windows system to test this, unfortunately. If you have issues, reach out to me and I can clarify this section with more details.

Using wget

Having installed wget we can now mirror (a.k.a. clone) some webpages. The distinction between which webpages this will work on and which it will not, are well beyond the scope of this post. For now, just try it. The worst case is that it won’t work. You’re unlikely to break anything.

Testing a single page

One of the issues of using wget is that you may accidentally bite off more than you chew, webpages can be very large and your local storage may not be big enough. Additionally, the bigger the webpage, the longer this will take, with no guarantee that it’ll work when it’s completed its job. Because of this, it’s important to test it on a small part of what you care about.

For example, if you wanted to mirror this website of a Russian and Soviet Journal, it will be wise to try and see if you can mirror one issue first. So let’s try to mirror the first issue from 2007. Below is the command that will try to mirror this particular page, but before you copy/paste it, read a little bit further so that you know how to change it to your needs:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent -l 1 http://zhurnalko.net/=sam/junyj-tehnik/2007-01

Everything from the wget to the --no-parent can be taken as a given for our ‘Quick and Dirty’ explanation.

The two important things for you are the following:

• -l SOME_NUMBER
• The URL (http://zhurnalko.net/=sam/junyj-tehnik/2007-01, in this case)

The -l represents how deep we want this mirror to go. You never want this number to be very high as it’ll try to download non-trivial portions of the internet. I’ve never used a number larger than -l 5, for instance and that can still take many many hours. Here we’ve started with -l 1 because we want this exact page and to follow each link on this page, the ‘1’ means “only go one page deeper”. Don’t ever use -l 0 though as that means ‘infinite’, which you don’t want, I promise.

The URL is the page we want to start from, in this case the first issue of 2007.

Now, when you run the command, it may take a bit of time. Just be patient, don’t put your computer to sleep or turn it off, or close your terminal/command prompt. Just let it do it’s thing. At some point, it will finish and you may get a message like the following:

Converted links in 87 files in 0.02 seconds.

Here, the 0.02 seconds is not for the overall process, but for the final step in making it available offline. The overall process took me about 5 minutes for this particular page.

Viewing the mirrored site

Unfortunately, this next part is going to be a bit different for each webpage. There’s not universal standard. I’ll try to explain what you’re looking for via our running example.

You’ll have a folder hierarchy that matches the URL you mirrored. In this case that means we’ll have a folder called zhurnalko.net/, and in the folder will be a folder called =sam/, which will have a folder called junyj-tehnik/. In that folder you’re going to look for something that is potentially called index.html, or index.htm. Sometimes, as is the case in our running example, it’s named the same as the last part of the URL: 2007-01.html, in this case.

If you try to open that (double click on it), you should be able to view the files.

Grabbing a bit more

Once you’re satisfied that the mirroring works, you can try to mirror a bit more of the website. This will require you going ‘up’ a level in the website, and adding 1 to the -l value you used. Remember, if that value starts getting large (you should consider 3 or greater to be large!), you’re trying to mirror too much and need to find a way to be more targeted.

In the case of the site we’re trying to mirror, one level up would be http://zhurnalko.net/journal-204, which has all the issues of that journal. We would then add 1 to -l and it would look like the following:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent
-l 2 http://zhurnalko.net/journal-204

To say that this could take significantly more time is an understatement. I ran the above over an hour ago and it’s still chugging along!

Once it completes its job, you’re going to want to find that initial page (see “Viewing the mirrored site” above) and you’re all set to use those files offline.

-JMCT

Aug 6, 2021

This year, Lindsey Kuper and I are co-chairing the Programming Languages Mentoring Workshop (PLMW) at ICFP 2021. The deadline to apply is August 8th, right around the corner.

If you’re someone that is curious about a career in a Programming Language-related field (whether that takes the form of attending graduate school, working in an industrial research lab, working on compilers/dev tools, or working in academia) I’d like to make a case for you to attend PLMW.

Many have made plenty of compelling cases before: Lindsey has a great post regarding last year’s event and many of those same points apply to this year’s iteration.

My case is slightly different than many of the discussions I’ve seen online, but before I get to it, I should state that my premise is based on the idea that research is a social process and activity. If you disagree with this premise, then I doubt you’ll be convinced by this post.

Good Research is Good Communication

Many of us pursue research ideas because we find them interesting or important or both (when the planets align). While it’s becoming more and more rare, it’s possible that a work of research is carried out alone by an individual and written up by that same individual. Once that paper is submitted though, the work leaves the realm of the individual and gets thrust into the sometimes arcane set of social processes, norms, and conventions of peer review. You are no longer a lone researcher exploring the wilderness of ideas, you have made your journey and now you must communicate what you’ve seen. This is hard.

Communicating ideas, particularly new ideas, is made more difficult when we don’t know who we are communicating with. By ‘who’ I don’t mean their identity, necessarily, but their general context and mental map of the world. As such, it’s important for researchers to attain a good working model of how their peers go about their work, what their peers find interesting, and what problems their peers are facing.

In programming languages we do this in several ways, but in my opinion the main two methods are:

1. Reading Papers written by our peers
2. Talking with our peers, directly

Conferences (or workshops, etc.) are great for the latter, especially if you already have a good mental map of who works on what and what the current techniques are. But if you’re trying to build that mental map, conferences can be quite intimidating!

PLMW as Map Making

In my view, PLMW is an on-ramp for making these mental maps of the community. No workshop will be able to just provide you with a fully up-to-date social graph of the community – everyone’s would be different anyway – but PLMW is designed to be a way for incipient researchers (and those curious about the field) to

• see what some of the current topics in the field are: Brigitte Pientka’s talk “Introduction to Mechanized Metatheory”¹
• learn how we communicate our ideas with each other: Derek Dreyer’s talk “How to Write Papers So People Can Read Them”
• discuss how we do research without knowing it all: the “I don’t get it” panel
• hear how to navigate explicit collaborative relationships, such as the relationship between a student and their advisor: Amal Ahmed’s talk “Managing Your Research, Your Advisor, Your PhD”
• think about how our research can have an impact on the world: Mike Hick’s talk “Increasing the Impact of PL Research”
• learn to view ourselves as emotional beings: Aaron Turon’s talk “Emotional Machines”

All of these topics involve social processes in some way, most do so directly.

We will also have small-group mentoring meetings so that you can ask more senior community members questions about doing work in the field, they are there to help you build your own map, so asking questions like “I’m interested in X, are there people/groups/etc. that look into X?”, or “I tried reading a paper on Y but I couldn’t understand it, what should look into in order to get the most out of that paper?” is the whole point!

PLMW may not be necessary for you, I won’t claim it’s necessary to attend PLMW, but everyone is welcome.

-JMCT

Jan 9, 2017

Preface

Welcome to part 2 of “The Burge School of Functional Programming”. Last time I claimed that Burge’s 1975 book “Recursive Programming Techniques” is a gem of Functional Programming that deserves to be more widely known. Burge’s book gets to the core of what Functional Programming is about, and it’s not fancy type systems or mathematical jargon; it’s expressions. This post is where we really pinpoint what an expression is. If I’m going to convince you that functional programing is about expressions, we should be really clear what we mean by that!

In later posts we’ll look at how to build up an entire programming language from what’s described here, and how that reflects one of the great ideas in Functional Programming: constructing software systems from small expressions that can be understood in isolation.

Throughout this series, I will use the notation that Burge used. However, I aim to point out when those notations differ from modern conventions.

I’m going to quote directly from the book a lot early on in this post, as I feel there’s a lot of insight to be found at the beginning of Burge’s first chapter.

Introduction

Burge hits the ground running with the introductory chapter of the book, making it clear that the style of programming this book advocates is a bit different from what the reader may be used to. On the very first page he states:

All the linguistic devices introduced [in this book] are based upon two methods of constructing expressions from smaller expressions […] Thus the extra notation that is added to this basis adds no new structural features

He names the extra notation additions. These days we would call it syntactic sugar, but the idea is identical: New forms of expression that can be translated to a few core constructs. Let that sink in: all of the language constructs that Burge describes in his book can be rewritten with just the two following constructs:

1. “An operator/operand construction that denotes function application”
2. “An expression format which denotes a function”

Burge does remind the reader that there will be some ‘constants’ (we’d call them primitives) required for certain tasks. This sets up one of the first great insights of the text, stating that the constructs

create a practical and powerful programming system, which is more like a family of programming languages than a single language, because the features introduced are concerned more with combining functions to produce new ones than with the nature of the primitive functions that are being combined.

Here comes the kicker:

A programming language for a particular range of applications can be obtained by adding an appropriate set of primitives to this basic structure.

These days we call a “language for a particular range of applications” a Domain Specific Language (DSL). DSLs are a very powerful tool in the functional programmer’s toolbox. So in just under a page Burge has set the stage for understanding functional programming through just a few core constructs and its usefulness in creating DSLs but avoids using any jargon. So Burge’s lesson so far: understand two core constructs, then pick primitives according to your domain.

We haven’t gotten much further in the decades since.

He’s not done yet, there’s one more insight waiting for us, right before he starts introducing the core constructs he reminds us that the focus is on expressions and not mechanisms. He argues that expressions have a great property:

the value, or meaning, of an expression depends in a simple way only on the values of its subexpressions and on no other properties of them.

So again, without leaning on fancy language, Burge lays it all out in front of us. He states that this property allows you solve large and complex problems by breaking them down into small, simple, and independent problems. And

it is possible to make the structure of the program match the structure of the problem being solved.

The Language

Operator/Operand Expressions

Let’s start with the obvious: Functional Programming deals with functions. This makes it critical to specify what we mean when we say function. Burge does this by talking about the relationship a function has to its arguments. More specifically, he talks about types, starting with function types.

But remember, this is a book from decades ago, so we’re not bringing in any heavy machinery here. Note that Burge never talks about type-checking or even implementing a type system. Even if your compiler doesn’t do type checking, you can still benefit from thinking about types.

Functions and types

I’ve been going on about expressions over mechanisms for a while and I haven’t even shown you an expression yet. So let’s take a look at one: \(f(x)\). This is how Burge typesets the application of the function \(f\) to the value \(x\). This is the first expression we’ve seen, so let’s unpack it. \(f(x)\) is a function application, which has two parts; an operator (in this case \(f\)), and an operand (in this case \(x\)). This makes function application a type of compound expression.

In the introduction I claimed that all of the language constructs we will introduce can be understood with just two concepts; function application is the first one! The basic idea of looking at application as a compound expression is that in order to make sense of the expression \(f(x)\) you’re going to have to make sense of \(f\) and of \(x\). That may seem obvious, but the insight Burge is trying to get across to you is that when you program in this expression-based style you make sense of each in isolation. That’s a very powerful idea!

Okay, so a function is a value that you can apply to other values (a.k.a. the inputs). However, not all values make sense as inputs; for example, the function \(square\) that takes a number and multiplies it by itself, does not make much sense if you give it the letter ‘a’ as an input. Let’s be a bit more concrete and say functions have a type, usually written as

\[A \longrightarrow B\]

Here the \((\rightarrow)\) is what indicates this is a function. The \(A\) is the type of value it accepts, and \(B\) is the type of values it returns. Burge calls these the domain and range, respectively.¹ So if you have a function \(f\) of type \(A \rightarrow B\), and you apply it to a value \(x\) which has type \(A\), the result is of type \(B\). Burge typesets function application as both \(f(x)\) or \(f\ x\).

Earlier I mentioned the function \(square\). One possible type for \(square\) would be²

\[square \in (\text{integer} \rightarrow \text{integer})\]

Other common examples:

\[ sin \in (\text{real} \rightarrow \text{real}) \\ log \in (\text{positive} \rightarrow \text{real}) \\ negate \in (\text{positive} \rightarrow \text{negative}) \]

So in general anything of the form \(g \in (A \rightarrow B)\) is an assertion that \(g\) is a function that takes arguments of type \(A\) and returns values of type \(B\). This means if we have a value \(x\) of type \(A\), we can be assured that \(g(x) \in B\).

Okay, this is all well and good, but every function we’ve looked at takes only a single argument, what about things like \(+\)? Here are some examples:

\[ + \in (\text{real} \times \text{real} \rightarrow \text{real})\\ min \in (\text{real} \times \text{real} \rightarrow \text{real})\\ equal \in (\text{real} \times \text{real} \rightarrow \text{truth value}) \]

This is just saying that these functions take two arguments, both reals, and return a single value. This generalizes in the obvious way to functions with an arbitrary number of arguments. So a function that takes \(N\) arguments would have a type like

\[A_{1} \times A_{2} \times \dots \times A_{N} \rightarrow B\]

Where \(A_{i}\) is the appropriate type of the \(i^{th}\) argument. In other words, \(A \times B\) defines the type of pairs where the first element is of type \(A\) and the second element is of type \(B\).

Now, the traditional way to apply functions that take multiple arguments is by extending the syntax we already have, giving us \(min(x,y)\) or \(+(x,y)\). Many languages have a predetermined set of special functions that can be applied differently, the arithmetic operations are usually such an exception, so you could write \(x + y\) instead of \(+(x,y)\). Burge is no different here and his language allows for certain functions to be applied in this special manner.

It’s worth pointing out that even if you have a special syntax for the application of certain functions, the operator/operand relationship is unchanged. It could be argued that allowing any such special syntax obscures this relationship and therefore obscures the meaning of the expression³. The important bit is that regardless of the syntax it is crucial that you be able to identify the operator and the operand of a function application.

Quick aside about types

This is pretty much the extent of what we’ll say about types, possibly for the whole series. Though types are used to describe things (as we’ll see in the next section), Burge never defines a type system, or any form of static enforcement of types. So why mention types at all? Because it’s important to think about types when you’re doing functional programming, particularly to distinguish between things that you can apply (functions), what they expect as argument values, etc.; and things you can’t apply (the number \(5\), for instance).

Many of the experts of dynamic languages I’ve interacted with will be the first to tell you: thinking about types is important when writing programs. But we don’t have to get fancy with our type system in order to have any benefit from the concept of types.

Meaning of expressions

We now know what makes up a function application (the operator and operand), but we still don’t know the meaning of anything. I claimed earlier that you can determine the meaning of a function application by finding the meaning of its operator and operand. But eventually you’ll reach an expression that is not a function application, Burge calls these simple expressions. In this section we will explain the meaning of one type of simple expression: constants (variables are the other type of simple expression, which we’ll get to a bit later).

In any programming system there is a set of constants (what we would call primitives). The meaning of these constants is given by the system and its implementation. The most obvious constants are things like numbers: \(4\), \(-128\), etc.⁴ or arithmetic operations: \(+\), \(-\), \(\times\), etc.

So if your language has the constant \(+\) which takes two numbers and adds them together, and it has numeric constants we can now find the meaning of expressions like \(+(4,5)\), or \(square(\times(2,3))\).

We do this with the following procedure:

1. If the expression is simple, what is the meaning of the constant?
2. If the expression is composite, what is the meaning of its operator, and what is the meaning of its operand?

Try applying this series of steps to \(+(4,5)\), or \(square(\times(2,3))\). Do yourself a favor and force yourself to actually go through the steps. In this instance it is not very hard, but it is the practice of finding the meaning of expressions via the meaning of their constituent parts that is important.

For the rest of the post we’ll allow ourselves to use the arithmetic operators as infix, i.e. \(4 + 5\).

What it means to be first-class; or, functions are values too!

Burge uses two conventions when writing function application. The first is what we’ve seen up to this point: \(f(x)\) or \(f(x,y)\). This is very common and is likely to be what most languages you’re familiar with use. The second convention Burge uses is more unusual: \(f\ x\) or \(f\ x\ y\), respectively. Burge explains that these aren’t really different syntaxes for function application, but really represent functions of different types!

It’s clearer with two argument functions. Take the functions \(addT\) and \(addC\)⁵, both of which add two numbers together. These are their types:

\[ addT \in (\text{real} \times \text{real} \rightarrow \text{real})\\ addC \in (\text{real} \rightarrow (\text{real} \rightarrow \text{real})) \]

The types tell us that \(addT\) takes a pair of real numbers and returns a real number, while \(addC\) takes a single real number and returns a function of type \((\text{real} \rightarrow \text{real})\). Therefore, when we write \(addC\ x\ y\), we’re really writing \((addC\ x)\ y\), i.e. we’re applying the function \((addC\ x)\) to \(y\). We can omit the brackets because function application associates to the left. Similarly the function type \((\rightarrow)\) associates to the right, so \((A \rightarrow (B \rightarrow C))\) is the same as \((A \rightarrow B \rightarrow C)\).

To really hit the lesson home, convince yourself that the following are all equivalent for a function, \(f\), that takes three arguments

\[ ((f\ x)\ y) \ z\\ (f\ x\ y) \ z\\ f\ x\ y \ (z) \]

and understand why \(f\ x\ (y\ z)\) is not equivalent to the three above⁶. Here’s a hint: think of what the operator/operand relationships are for every function application, even the symbols within brackets.

For extra credit, draw a tree of the operator/operand (function/argument) parts for each version, including \(f\ x\ (y\ z)\).

This is not just some clever rationalization of multi-argument functions, this is a direct consequence of functions themselves being values. Because they are values just like anything else we can also pass functions to other functions, take the following example:

\[ twice\ f\ x = f\ (f\ x) \]

\(twice\) is a function that takes two arguments, a function and some other value, and then applies the function ‘twice’ to the value. So if we had a function \(add\text{-}one\) which adds 1 to a number and called \(twice\ add\text{-}one\ 5\) we would get 7.

Treating functions as ‘first-class’ values has become quite ubiquitous these days, and for good reason! First-class functions allow you separate the form of a computation from the task being accomplished. This is one of the more powerful ideas from functional programming, and as such, Burge will explore it in depth later on.

Variables and Lambdas

Up to now we’ve used variables without discussing them, because many of us will have an intuition for what variables mean from other languages or from algebra in school. In this section we’ll be more precise about what a variable means.

Take the following mathematical equation:

\[ f\ x = (5 \times x) + 2 \]

This is a function over the variable \(x\). When you plug in different values for \(x\) you get different results.

There are two very important properties about variables like the ones in the equation above. The first is that it doesn’t matter what name we give \(x\): \(f\ y = 5y +2\) is the exact same equation with the exact same meaning. The second is that in mathematics we don’t actually change the values of a variable: Once we’ve plugged in a value for \(x\) that value remains the same.

To better formalise how variables work we’ll use a notation developed by Alonzo Church. The following defines the same function using lambda (\(\lambda\)) notation:

\[ \lambda x.(5 \times x) + 2 \]

We haven’t given the lambda expression a name, which is why in some languages they call lambdas ‘anonymous functions’. There’s nothing stopping us from giving the above a name though

\[ f = \lambda x.(5 \times x) + 2 \]

defines the same function again, this time giving it the name \(f\). Here is the crucial point: \(f\ x = (5 \times x) + 2\) and \(f = \lambda x.(5 \times x) + 2\) are the same function.

Taking lambdas apart

In the same way that function application had two parts, the operator and the operand, lambda expressions also have two parts: the bound variable and the body. Everything between the lambda (\(\lambda\)) and the period (\(.\)) is the bound variable and everything after the period is the body.

Lambda expressions are functions, which means you can apply values to them (i.e they can be the operator part of a function application). When you apply a value to a lambda expression you substitute that value wherever the bound variable appears in the body and get rid of the bound variable part of the lambda expression, leaving only the body. So \((\lambda x. x + x)\ 5\) becomes \(5 + 5\).

We can happily pass lambda expressions to other functions as well (since they are values themselves). Remembering the definition of \(twice\) from earlier, the expression

\[ twice\ (\lambda x. x + 1)\ 5 \]

is equal to \(7\).

What about multi-argument functions? Well we already learned that multi-argument functions are just single argument functions that return functions, so let’s apply that idea here and define \(add\) with lambdas:

\[ add = \lambda x.\lambda y. x + y \]

This actually makes what’s happening when we partially apply a function more clear. If we only pass \(add\) one argument what do we get? \((\lambda x.\lambda y. x + y)\ 1\) becomes \(\lambda y. 1 + y\), or the function that adds \(1\) to its argument.

Expressions

So we’ve spent a lot of time going on about function application, lambda expressions, and simple expressions (constants and variables). What do we know now? Well we know all the forms an expression can take. To paraphrase Burge:

An expression is

• either simple and is a identifier
• or a lambda expression + and has a bound variable which is an identifier + and a body which is an expression
• or it is a function application + and has an operator and an operand, both of which are expressions

In the next post we’ll show you the language Burge describes in full, but it’s important to emphasize: Every language construct we will show you can be translated to expressions consisting only of what’s described above. A whole family of languages arises from the three possibilities above. As promised, we have two ways of combining expressions: lambda expressions and function application. The only other piece is that we need a way to refer to things, which is where the identifiers (variables or constants) come in..

Conclusion

The core of Burge’s book, and Functional Programming more generally, is in what is possible with expressions. From this fact stems a lot of what makes Functional Programming such an interesting and exciting field. It affects the way we think about data, the way we think about program structure, and even how we implement our languages. Once equipped with these tools it’s easy to see the shared principles of all functional languages.

It’s very easy to get intimidated by a lot of the language that is thrown around in certain Functional Programming circles these days, but rest assured; understanding expressions and how we can reason about them and manipulate them gets you much further than diving into arcane mathematics ever will.

The rest of the series is going to be a pretty crazy ride, and it all comes back to what we’ve learned here; that expressions come in three mains forms: identifiers, function applications, and lambdas.

Buckle up.

Epilogue

Josh Triplett, Kelley Robinson, Heather Miller, Rob Rix, and Michael Banks all gave constructive feedback on drafts of this post. Thank them if any of this made sense.

And of course, as promised, we’ve got another Prog Rock hit from the early 70’s, this one’s about a show “you’ve got to see”, a.k.a. how all of the language constructs we are used to can be made up of just expressions ;)

-JMCT

Dec 23, 2016

Preface

This is the first in a series of posts about what I am calling the “Burge School of Functional Programming”. When I originally tweeted that I was going to do this, I called it the “Burge-Runciman” School, but upon further reflection I think that they are distinct and I was being clouded by the fact that it was Colin Runciman who taught me about Burge.

Motivation

There has been a lot of discussion online in the past few years about what Functional Programming is. This discussion comes in waves and we recently had a high-point when a list claiming to classify levels of Functional Programming was widely distributed.

I, as well as many of my colleagues, found the list a bit disconcerting. It is a dangerous game to try and make such a prescriptive list about a topic; it is a near certainty that any benefits of such a list are far outweighed by the likelihood of any such list alienating those who are looking to get started in Functional Programming.

Independent of the situation I just described, I’ve been dissatisfied with the attitude that Haskell is the ‘truest’ Functional Language, or that it somehow exhibits FP in its ‘purest’ form. Because of this I have wanted to write about some Functional Programming history for a few years now. In particular I want to draw some attention to William H. Burge’s book “Recursive Programming Techniques”, which is a (sometimes forgotten) gem of Functional Programming.

Background

When I was a PhD student at York, I remember reading a paper about parser combinators in Haskell. I went into Colin Runciman’s office and expressed my joy, and in particular I expressed something like “it’s amazing that they were able to come up with something like that!”. This was early days of my PhD when I still wasn’t so great at identifying what’s actually novel in a paper. Colin told me to wait a minute and he went to his bookshelf and grabbed an old book: “Recursive Programming Techniques” by William H. Burge. He suggested I read it.

The book was first published in 1975, three years before Backus’ famous Turing award lecture “Can programming be liberated from the von Neumann style?”, which is often seen as a watershed moment in the history of functional programming because it brought so much attention to the field. In my view Burge’s book has aged much better than Backus’ lecture, but that is likely due to other factors.¹

The Burge School

Burge’s book is, in my opinion, one of the best publications on what functional programming is about. This is made even more intriguing when you think about what wasn’t around when this book was first published. In 1975 we did not have:

• Polymorphic Type Inference
• Algebraic Data types
• Lazy languages²
• Lots of Category-theoretic terminology as part of functional programming

This is in contrast to how many commentators online talk about functional programming. However, much in the same way that music is not a set of instruments, functional programming is not a set of abstractions that we need to learn and memorize. Functional programming is an approach to solving computational problems.

Many of the abstractions that you do read about are ways to apply this approach to new problems, or problems that were difficult to solve without reaching for more traditional programming methods. But the essence, the core, of what functional programming is about is mostly unchanged.

In the preface to the book Burge writes (emphasis mine):

The main emphasis [of this book] is placed on those parts of the language, namely expressions, that denote the end results sought from the computer, rather than on the instructions which the machine must follow in order to achieve the results. The main thesis of this book is that, in many cases, this emphasis on expressions as opposed to mechanisms simplifies and improves the task of programming.

The above will be familiar to anyone who has had the good fortune of taking a well designed functional programming course. This is the paradigm shift that sometimes makes functional programming hard to learn for those that are used to other methods of programming. Expressions over mechanisms.

The Book

Part of what makes this book so interesting is that it was published as part of a series on programming from IBM. The series was called “The Systems Programming Series” and its charter was

a long term project to collect, organize, and publish those principles and techniques that would have lasting value throughout the industry.

IBM was trying to combat the tendency for systems programmers to all continually reinvent the wheel. In other words, this was not a series for the navel gazers in the Ivory Tower, this was for those on the ground programming real systems and solving ‘real world’ problems. Granted, the programming tasks of the day weren’t necessarily the same tasks that a programmer today might be focusing on, but the tools and techniques are more similar than one might think.

The book itself is divided into 5 chapters:

1. Basic Notions and Notations
2. Program Structure
3. Data Structures
4. Parsing
5. Sorting

In the coming weeks we will take a look at each chapter and highlight Burge’s insights. The goal here is to provide a counter to the checklist approach to functional programming material. The core ideas are all here, my hope is that once those are internalized a lot of the modern discourse on Functional Programming can be seen in a new light.

Epilogue

Many of the older functional programmers I know were big Prog Rock fans. I find it fitting that many of those that were early proponents of what was a radical programming methodology were into radical music as well. I don’t know Burge, but I like to imagine that the soundtrack of the 1970’s was in the air as he was writing this book. With that spirit I’m going to link to a Prog Rock hit from the early to mid 1970’s with each post; because, why not?

So, for all of those early functional programmers that were called ‘dreamers’:

-JMCT

Apr 24, 2015

I just heard, via the Hudak family’s caringbridge journal, that Paul Hudak is in critical condition and unlikely to be with us much longer. My heart goes out to Prof. Hudak’s loved ones in these final moments.

As with many others, Prof. Hudak has had a huge influence on my work and the way I view functional programming. His book “The Haskell School of Expression” (and later “The Haskell School of Music”) introduced artists to functional programming and functional programmers to art. The Haskell School of Music is especially good at being both a programming text and an introduction to computer music (I wish the book had been around when I did my Music Engineering degree).

His influence on programming languages as a discipline is well known. His work was always the right combination of rigorous, interesting, and elegant. He advocated for the use of denotational semantics not only as a tool in specifying the behaviour of programs¹ but as a sanity-check on an idea, arguing that if a language feature could not be elegantly expressed in a denotational semantics then the feature should be reconsidered.

He was also unafraid of expressing unpopular opinions. In a Haskell mailing list post he decries the overuse of ‘do’ notation, claiming it obscures, rather than reveals, what’s happening in a program. Having taught hundreds of undergrads Haskell for a compilers course I’ve come to appreciate Hudak’s point. I now start new Haskellers off using explicit (>>=) and lambdas over ‘do’ notation until they understand the underlying structure, then when they graduate to ‘do’ notation there are far fewer students who get thrown when using monads.

On top of Prof. Hudak’s many accomplishments he was known as a very gracious and generous man. I could repeat one of the many stories I’ve been told about him but instead I’ll share the one personal story I have.

I was fortunate enough to meet Prof. Hudak at ICFP last year. I was taking a break during one of the sessions and he was outside relaxing and, in his own words, “dealing with jetlag”. I introducted myself and we had a long chat about functional programming, implicit parallelism, Prof. Colin Runciman (my supervisor), and of course music. One of the interesting things about researching implicit parallelism is that the functional programming community is very split on the idea. Some feel very strongly that it can’t work and is a waste of research effort, while others are excited by the idea and are happy that someone is working on it. When I told Prof. Hudak what I was working on he got excited and was extremely supportive. If he held any doubts about the plausibility of the idea he was gracious enough to put them aside and chat with me about it.

Throughout the rest of the conference he would often come up to me for a quick hello. A few days later he and his PhD student, Dan, invited me to go to the theme park that was near the ICFP venue with them. I turned them down as I ‘had’ to work on a paper². In those few days of speaking with Prof. Hudak it was clear that he was as gracious and humble as he was brilliant.

My story is not unique, literally every person I have spoken to about Hudak and his work has commented on how nice/generous/humble he was. In a world full of egos and me-firsts, Prof. Hudak embodied what academia should be about: sharing your ideas with others and hearing their ideas, no matter who they are (even star-struck PhD students).

-JMCT

Nov 18, 2014

Hello World Wide Web,

I’m a final year PhD student at the University of York, and this is my website.

You’ll probably find posts on Haskell, which looks like this:

    map :: (a -> b) -> [a] -> [b]
    map f []     = []
    map f (x:xs) = f x : map f xs

Or alternatively, you’ll see posts about making bread, which is my current fascination.

-JMCT