How can those of us working in industry, often with frustrating languages and broken tools, help to transition that industry towards Functional Programming? How can we educate our coworkers, our managers, and even our clients that FP is not only helpful, but invaluable? This talk will introduce ReasonML, Facebook’s gambit towards transitioning JavaScript and PHP Web developers towards FP semantics and safety. Built as a syntax over OCaml, it is being designed and curated as a way for us to introduce these principles into our daily work and help our industry towards writing better, safer code.
This talk will introduce the language and the ecosystem, show its strengths and weaknesses and discuss where it might be an appropriate lever to introduce a team to FP with minimal disruption.
Workshop:
Building on the information in the talk, this workshop will show you how to build functional, typed UI systems in ReasonML. Using the bindings to the React library, we’ll go from the basics to building our own copy of Minesweeper, and time permitting, beyond.

Attendee requirements:

Meet Schrödinger, who travels the world with an unusually clever clowder of n talking cats. In their latest show, the cats stand in a line. Schrödinger asks a volunteer to take n+1 hats, numbered zero to n, and randomly assign one to each cat, so that there is one spare. Each cat sees all of the hats in front of it, but not its own hat, nor those behind, nor the spare hat. The cats then take turns, each saying a single number from the set {0..n}, without repeating any number said previously, and without any other communication. The cats are allowed a single incorrect guess, but otherwise every cat must say the number on its own hat.

In this talk, we’ll methodically derive a solution, and we’ll formally prove that the method always works. Along the way, we’ll reinvent some elementary theory of permutation groups, in particular, a parity property. You’ll get a taste of what it’s like to formally model a problem in Isabelle/HOL, and prove properties of interest. This is the same theorem prover we use to prove the functional correctness of the seL4 microkernel.

For more information on the topic, see the GitHub repository.

Graphics, animation, and games programming in Haskell faces a dilemma. We can either use existing frameworks with their highly imperative APIs (such as OpenGL, Cocos2D, or SpriteKit) or we waste a lot of energy trying to re-engineer those rather complex systems from scratch. Or, maybe, we can escape the dilemma. Instead of a Haskell program directly manipulating the mutable object-graph of existing high-level frameworks, we provide an API for purely functional transformations of a Haskell data structure, together with an adaptation layer that transcribes those transformations into edits of the mutable object-graph.

In this talk, I will explain how I used this approach to architect a Haskell binding to the animation system and physics engine of Apple’s SpriteKit framework. I will discuss both how the binding is structured internally and how it achieves the translation of Haskell side changes to SpriteKit and vice versa, such that it is sufficiently efficient. Moreover, I will explain how to use the Haskell library to implement animations and games.

Many useful operations are well-defined on functions but are not computable, e.g., root-finding, optimization, exact differentiation and integration, and efficient, incremental evaluation. Sometimes these problems can be solved by means of a domain-specific embedded language (DSEL) with an implementation that maintains extra information. With extra effort, these implementations can be quite efficient, but at the cost of duplicating work of the host language compiler. Although overloading can hide some of the required change of vocabulary, the illusion is imperfect, and so code must be rewritten for the new DSLs with sometimes awkward or surprising results.

This talk presents an alternative to DSELs, giving new interpretations to existing functional programs. The implementation is a plugin for GHC—a popular, high-quality Haskell compiler—and works by translating to a well-known, more easily generalizable form. Each new interpretation is simply a new type and a collection of class instances for it, written in standard Haskell, with no exposure to compiler internals. To get a feel for the breadth of this technique, we’ll look at interpretations including hardware circuits, automatic differentiation, incremental evaluation, and interval analysis.

Over the last year at Zova I’ve rewritten our iOS app from scratch, with RxSwift at the core. This talk will cover some of the techniques and patterns used to cross the bridge from the world of iOS apis, with its delegates, callbacks, NSNotifications, and KVO, to the promised land of FRP, with an app which is largely reactive, stateless, and declarative.

Firmware has historically been written in C, and as such has generally been very imperative in nature. With modern devices like the Raspberry Pi Zero and more recently the Rasberry Pi Zero W, embedded processors can now happily run a linux stack on a very small footprint with low power draw.

All this means that we can look past C for writing firmware. Elixir’s heritage in Erlang – running telephone switching – means that it is uniquely equipped for dealing with the demands of firmware. In this talk we’ll look at how you can use Erlang, and more specifically Nerves, to build your own firmware.

This talk includes not only live coding, but live deployment on real hardware. Hold onto your hats, the actor pattern is being unleashed on the physical world.

Workshop requirements: https://mootpointer.github.io/functional-firmware/

Functional programming is a useful technique. We spend a lot of time discussing it in the context of hard, challenging or interesting problems, but no where nearly enough in the context of mundane problems.

The UNIX shell, or command line interpreter. A simple, but useful program too often mistaken as complex, or mysterious. Almost every programmer is exposed to shells from a users perspective, but far fewer have ever implemented one, or even know where to start.

This talk aims to be a fun look at using functional programming in and around a traditional, some would say mundane, system utility. We will work through the concepts involved with implementing your own shell, and live code our way to a basic functional shell implemented in Haskell.

From this talk, attendees will walk a way with a better understanding of a program they use every day, as well as ideas and inspiration around using functional programming to solve mundane programming problems.

WORKSHOP/CODE JAM – 120mins

Time to get hands-on. In the talk ‘Mundane Utility: A Functional Shell’ we learned the basic responsibilities and structure of a shell, now is the opportunity to build a shell optimized for you.

In this jam, you will be asked to build up your own shell. There will be a starting structure in Haskell, but the problem can be approached in almost any language with decent Unix and process management APIs.

To solve the problem, you will need to tackle: command parsing and validation; concurrent process management; and input/output handling. Throughout the jam we will work through neat functional solutions for each of these, as well as looking at the overall approach to designing a robust functional program.

At the conclusion of the jam we will compare the solutions and the potentially unique features that appear from people tackling this problem in a novel, functional, manner.

If you are at this conference, you probably understand the benefits of functional programming and like me, would love to see it more widely adopted. Despite all the advanced topics at this conference, functional programming is not new. Yet, more than 80 years after the introduction of lambda calculus it is still a “niche” skill, practiced rarely in enterprise software development, requested rarely in job adverts, found in few developers, even less in senior developers, and frankly viewed with suspicion and dread amongst engineering managers and CTOs. Why is that, and can we change it?

Three and a half years ago, I was an experienced, productive Senior OO Developer, the master of several mainstream languages, proud of the quality production software written by my team. In fact, I was just the sort of developer least likely to embark on the significant FP learning curve.

But then I was fortunate enough to find myself at REA Group just as some brave pioneers experimented with the company’s first foray into the FP programming paradigm.

Three years later, we can declare their efforts hugely successful, with functional programming fast becoming ubiquitous at REA Group, ever more widely practiced, understood and appreciated. More importantly, this momentum is ensured by the mutation of senior developers such as myself into powerful advocates for FP.

So what were the key ingredients to this success, and how can you replicate it at your organization? How did they manage to mutate us immutable senior developers, and convince managers that the considerable learning investment was justified?

This talk will look at both REA’s journey, and my own personal journey to answer these questions. It wasn’t all plain sailing, and I will identify the key ingredients of this success as well as the obstacles with the strategies that ensured they were conquered.

27 years ago I published “Why Functional Programming Matters”, a manifesto for FP–but the subject is much older than that! In this talk I’ll take a deep dive into its history, highlighting some of the classic papers of the subject, personal favourites, and some of my own work. At the end of the day, four themes emerge that characterize what I love about the subject.

This talk will demonstrate the use of continuation-passing style to solve common and eternal practical problems in Haskell. It aims to illustrate that a range of seemingly magical techniques are comprised of little more than judicious use of CPS, changing the structure of constructed expressions without affecting their meaning.

Whether you’re tackling classic inner-loop optimisations like difference lists (DList) or builders, reshaping the spine of an expression to manage lazy side effects, or using the Codensity transform to improve the asymptotics of your free monad, it’s continuations all the way down.

The aim of this talk is to provide some visual and practical intuition for difference lists, then deconstruct scary pieces of jargon until they look like difference lists. We gain some concrete intuition for CPS, and controlled lazy evaluation. We demonstrate that many advanced concepts are little more than an accretion of simple, powerful techniques, of which lambda is the ultimate.

This hands-on, code-centric session teaches attendees how to use the Eff monad library to build a directory scanner in Scala.

The Eff library is an implementation of Extensible Effects in Scala, developed by Eric Torreborre. It is inspired by Oleg Kiselyov’s Haskell paper ‘Freer Monads, More Extensible Effects’ . Like Monad Transformer stacks and the Free monad, it provides an organising principle for the construction of pure functional programs.

This workshop focuses on teaching attendees how to use Eff to solve an applied software engineering problem, namely a directory scanner. It introduces several common Eff ‘effects’ through 5 incremental exercises:

• The Async effect to model asynchronous requests
• Using Either effects for error handling
• Using Reader effects for dependency injection
• Writer effects for logging

Materials are available at benhutchison Getting Work Done With Extensible Effect. Solutions are included for all exercises.

There is a paradox in the foundations of computing. On the one hand, lambda calculus is supposed to compute anything that can be computed. On the other hand, many intensional computations, such as deciding equality of programs (terms in closed normal form), are not definable within lambda calculus. The paradox has now been resolved by close reading of the original papers and books, which clarifies that lambda calculus is inherently extensional.

More importantly, there are new, intensional calculi which are more expressive than lambda calculus. First, pattern calculus supports both higher-order functions and generic queries of data structures, by basing all computation on pattern matching. Second, SF-calculus can query programs as well as data structures by factoring them, using the operator F. In particular, the Goedel number of a program can be defined within the calculus itself.Third, lambda-SF calculus adds native support for lambda-abstraction to SF-calculus. Other calculi are currently under development.

Pattern calculus has been realised in the programming language, bondi. Even better programming languages are now possible.

Haskell often lends other programming languages ideas, but what can Haskell learn from other functional programming languages?

In this talk I’ll adapt Clojure’s transients to Haskell, and fix them up along the way with the help of Haskell’s type system features.

Transients are immutable data structures that can be made mutable in O(1), and frozen again in O(1). Unlike with Haskell’s arrays, which support superficially similar freeze and thaw operations, this doesn’t ‘destroy’ the frozen structure.

I’ll show the naive translation, a not-so-dirty trick to make it fast, how to layer a more Haskell-like mutable API on top, then borrow some more improvements from recent work on similar structures in Scala and Clojure.

The redux architecture seems to have really won over the React community, which is awesome to see because it was inspired by a purely functional, typesafe language called Elm.

This talk will quickly look at ‘The Elm Architecture’ (TEA) and explain why the shape of the architecture works so well to create purely functional HTML UIs. This language / architecture has been very popular with JS devs and is worthwhile taking a peek at this typesafe thing that is capturing the attention of mainstream developers.

TEA is limited by it’s intentional anti-modularisation of the program state and update commands. The bulk of this talk will look at a purescript library called Halogen and how it takes TEA to a modular and typesafe state with components only having localised state and communicate only via explicit messages sent between components.

This intention of this talk is not to posture one as better than the other, but to talk about the shapes of each and why one or both may be worth your interest. Even if neither quite work for your use cases, it is still very useful to understand where people are pushing the bounds of typesafe SPAs.

Attendee Requirements:

• Internet connection
• Laptop w Pre-requisite software installed (will be provided)

Haskell encourages creating as many data types as are needed to model the problem domain correctly. However, often they need to implement one or several helper typeclasses, with trivial implementations possible. Generics make it possible to describe the rules for producing such implementations once, and use those for all the created data types, reducing the amount of boilerplate and errors.

Functional programming is a great tool for enabling programmers to solve complex problems through the use of data and functions. However, not all data and functions are created equal, and some are less composable than others. Web libraries in particular are guilty of being overly opinionated and ending up as closed worlds of functionality. As programmers we are complicit whenever we find ourselves asking: “What web framework should I use”? But why do we need to choose a single framework in the first place? Why can’t we compose functions from different libraries? Do we really need 5 different ways to get/set a cookie?

This talk aims to deconstruct what we typically expect from a web framework, and how we can achieve the same functionality with a series of small, composable functions. This will be demonstrated using Haskell’s WAI library as a common building block, and contrasted to the equivalent implementation in other modern Haskell web frameworks. By the end of this talk web frameworks will be demystified and exposed for what they should be – a collection of composable functions. In addition the audience will have gained confidence in their ability to recognise good and bad functions, and to better evaluate the cost of the libraries they inhabit.

Lenses, or more generally “optics”, are a technique that is indispensable to modern functional programming. However, implementations have veered between two extremes: incredible abstractive power with a steep learning curve; and limited domain-specific uses that can be picked up in minutes. Why can’t we have our cake and eat it too?

Goggles is a new Scala macro built over the powerful & popular Monocle optics library. It uses Scala’s macros and scandalously flexible syntax to create a compiler-checked mini-language to concisely construct, compose and apply optics, with a gentle, familiar interface, and informative compiler errors.

In this talk I’ll introduce the motivation for lenses, why lens usability is a problem that badly needs solving, and how the Goggles library, with Monocle, addresses this in an important way.

Unless you’ve been hiding under a rock, you’ll probably have heard of blockchains. What you may not know is that this data structure is an instance of a data structure known as a Merkle list. Blockchains, in turn, often contain Merkle trees of transactions within them. However, the literature tends to talk about these data structures in a fairly ad hoc way. This talk will introduce Merkle data structures, show how to automatically generate them from the algebraic representation of their type, and investigate an interesting correspondence between zippers, the integral calculus and Merkle set-membership proofs.

QuickCheck is a shockingly effective tool for validating the initial and ongoing correctness of production software. One of QuickCheck’s most compelling features is that when a test failure is found, the failing test case is simplified to a minimal counterexample, through a process called shrinking. This makes it significantly easier to understand why a test has failed.

The Haskell version of QuickCheck, and most of its derivatives, tackle shrinking in a type-directed fashion. Quiviq’s Erlang version on the other hand, and a few similar tools for other dynamic languages, couple their shrinking capability directly with their test data generators. Now, types are good, right? So surely the Haskell version is better! Why wouldn’t we want to use types to guide our shrinking process?

In this talk, I will highlight the technical and social problems that we, at Ambiata, experienced with type-directed shrinking. We’ll explore the alternative, integrated shrinking, and we’ll see that even in a statically typed language, integrated shrinking provides enormous benefits for developer productivity. We will see how to implement integrated shrinking, using rose trees, in the context of a strong statically typed language. Finally, we will see how to create a rose tree monad transformer, a tool which will allow us to create effectful test data generators, which still shrink properly!

From this talk, the audience will learn about the difference between type-directed and integrated shrinking, and how integrated shrinking can provide superior counterexamples, while placing a smaller burden on developers writing tests.

There’s no such thing as the perfect programming language. I’m sorry, but there isn’t, and I’ll explain why.

On the other hand, if you were set the task of designing the perfect language, how close could you get, how would you go about it, and what would it look like in the end? We’re going to explore this problem space with a tour along the bleeding edge of modern language design, giving you some insight into what’s already out there, what tradeoffs each new idea comes with, and what sort of tools you might be working with in a future where programming is slightly less awful than it is today.

When managing systems we often use imperative tools. We run commands and mutate state. Nix provides tools to convert imperative commands into functions. By using functions we gain code reuse, reproducibility and atomicity.

Nix’s tooling consists of a programming language, a package manager and an operating system. Using these tools we can define packages, cross-compiled binaries, chroot environments, virtual machines and Docker images.

This talk will skip the basics of how to use Nix and instead cover the basics of how Nix works, some of the benefits it gives and how I’ve been using it personally and professionally over the past few years.

[tt_timetable event=’nix-functional-systems’ columns=’sydney-day-1-green-mon-08-may-2017′ time_format=’H:i’ hide_hours_column=’1′ event_layout=’3′ box_bg_color=’eeeeee’ box_hover_bg_color=’eeeeee’ box_txt_color=’333333′ box_hover_txt_color=’333333′ box_hours_txt_color=’333333′ box_hours_hover_txt_color=’333333′]

GHC usually does an excellent job of transforming well written Haskell code into efficient machine code, but sometimes “fast” is not “fast enough”. Common optimisation techniques when dealing with concrete data types often do not apply to polymorphic data and functions. A concise, generic algorithm may perform poorly for some types, but providing a faster version with a less polymorphic type sacrifices reusability and parametricity! What’s a principled programmer to do?

Fortunately GHC has got your back here, too. In this talk we will learn about GHC’s *rewrite rules* feature, which can be used for substituting alternative, better performing implementations of polymorphic functions at particular (less polymorphic) types, without changing the type signature that users see, preserving reuse and parametricity. We will see also how to define transformation rules that employ theorems (free or otherwise) to optimise programs.

We will also briefly examine how rules are applied by observing the firing of rules and changes effected in the produced Core (GHC’s fully desugared intermediate language), and see how to control the order of inlining and rewrite rules to achieve the desired outcome.

Finally, we’ll look at a real-world example of how rewrite rules are used in the ‘fresnel'[1] library, a unified parser-printer combinator library based on the ‘Cons’ abstraction from the ‘lens’ library, to dramatically speed up printing for certain output types.

This will be a hands-on talk with live coding, benchmarking and profiling (no optimising without metrics!) and Core spelunking. Audience members familiar with Haskell should expect to learn some basics of Haskell benchmarking and profiling, gain an understanding of when and how to use rewrite rules in their own code, and walk out feeling comfortable (or less trepidatious, perhaps) about reading and analysing their programs’ Core.

Functors are ubiquitous in modern strongly-typed functional programming. Every Haskell beginner will come across them as one of the first typeclasses introduced. Stronger structures such as Applicative and Monad often steal the spotlight, but there are many structures related to the humble Functor that go unnoticed. The goal of this talk is to show off and give an intuition for some of these other structures: contravariant functors, bifunctors, and profunctors. With some of these making their way into Haskell’s standard library recently, now is a perfect time to be introduced to or brush up on these concepts. Code examples will use Haskell, but these techniques extend to any language with typeclasses or a similar mechanism, such as Scala’s implicits.