I've been working on a logic programming framework in Haskell, called guanxi (關係) with an eye towards scalability. To build it I leaned heavily on my previous work on propagators and a bunch of other little bits and pieces of algebra and category theory in the design process. A number of patterns have arisen repeatedly throughout the process of building this library. I'll give a tour through the current state of guanxi and try to extract some of the more reusable bits of its design for your inspection.

Programs are getting fat. They're becoming slow. They're taking up more computing resources. They're getting harder to maintain and more complex from the ground up. Layer upon layer of sophistication is causing us to lose our ability to predict what software will do. Where's that bug? Why is everything going so slowly? Am I even using the right data structures? Where's that important point in the documentation again?

What's happened to us? In this meta-dive into the nature of our approach to programming, we will explore some of the dangers of our current approaches to programming and the how/why of our current programming obesity problem. We will look at real case studies and see just how bad the situation can be.

But we will also explore how we can battle these sources of obesity. In this passionate plea for code that we can gain control over again, we will look at examples of how we can return to a state of high-performance on all levels, from code size to code scalability. We will look at the principles that can help us to reach leaner, more efficient, more usable, less buggy code. We will hopefully find some light at the end of the tunnel, and how we can change our outlook on programming to push ourselves towards code that benefits not only ourselves, but also those that will come after us.

There are a lot of algorithms that revolve around iterating a form of information propagation until it attains a deterministic fixed point. CRDTs, Datalog, SAT solving, functional reactive programming, and constraint programming all fit into this mold.

One framework for these sorts of algorithms is the notion of a “propagator” due to Sussman and Radul, but until now little rigor has applied to know how such algorithms terminate with consistent results. Another framework is Lindsey Kuper’s work on the notion of “lattice variables” (LVars), which addresses termination, parallelism and eventual consistency well, but not iteration.

By blending these frameworks, I’ll build up a series of sufficient conditions for propagators to terminate with consistent results and proceed to show how we can use this common framework to steal insights and quirks from each individual domain to try to optimize the rest.

If you are writing a stateless web application backed up by a database, there is a good chance Elixir is a great fit. However, this is not where it shines. In this talk, we will discuss how to architect Elixir applications in order to leverage the features of the language and of its runtime.

Have you ever wondered what happens beneath the covers when you talk to your Database? Well, you are in for a treat! In this talk, we are going to uncover the dark magic behind Database Drivers. We will look at everything that is needed to talk to a database, query its data and transform it into the native data types in Elixir.

In this talk, we go back to first principles, defining and examining the definition for a cons list, then take a look at the ubiquitous right and left fold functions on a list.

The primary focus of this talk is to develop an intuition for how these functions work so that we can best decide when to apply them. Multiple programming languages will be used to help emphasise the independence of the gained intuition. This talk will generally be interactive with the audience as we solve problems and build confidence in our new knowledge.

Knowing how to apply the various list fold functions is a common question by the student of FP. This talk aims to provide a solid, reliable answer to this question. No prior understanding of list folds is necessary.

The term zipper is a colloquial used to describe n-hole (most often, 1-hole) contexts. That is, a data structure that has a _hole_ or _pointer_ focused on a specific element with the ability to efficiently traverse to its neighbouring elements, providing an elegant solution for the need to efficiently traverse and _modify_ immutable data structures.

In this talk, we will look at examples of zippers for canonical data structures such as lists and other products and sums. We will then define comonads and see the relationship between zippers and comonads.

Most of this talk will be spent on the practical application of zippers in everyday programming. We will solve some simple problems using zippers. We will then contrast why we might use a zipper, compared to a lens.

Finally, for a fun and interesting observation, we will look at the algebraic structure of products and sums, then compute the derivative of these structures. Turns out, a derivative of a data structure is its zipper ("McBride, Conor, et al (2005). ∂ for Data: Differentiating Data Structures").

I got excited about property-based testing after hearing John Hughes talk at Functional Conf 2016. I tried it that year with QuickCheck, but failed miserably (it almost derailed the entire project delivery). I cribbed about it in my talk at Functional Conf 2017. In 2018, Srihari's talk got me excited again. This time, I tried with Hedgehog, and got it to work!

This talk is about this journey and its learnings. We'll talk about how Hedgehog was used to test [1]:

• A Postgres backed task/job queue
• A small Wai/Servant based webapp

And no, we will not talk about the most common (and completely useless) example of reversing a list!

[1] Both of these are part of an open-sourced task/job queue library.

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

Elixir is a modern programming language built for concurrency, robustness, and maintainability. Although the Elixir team comes from “industry” backgrounds, the history of Elixir is full of cases where the team has reached for existing research in order to solve problems arising with the language. For example, we based our implementation of a code formatter on a series of papers on pretty printing and formatting code. In this talk, I’d like to go share our learnings and experiences as a bunch of industry folks getting help from academia to approach and tackle real-world problems and come up with real-world solutions.

As machine learning matures, it is becoming obvious that we need explainable solutions. As functional programming matures it becomes obvious that we need inference and nondeterminism. And linked open data demands reasoning. This all day workshop will introduce the logic programming paradigm, in which programs are expressed as a set of logical rules and executed by finding proofs of queries.

SWI-Prolog is the most highly developed and widely used language for logic programming.

The language, which has been in continuous use in academic research settings since it's invention in 1972, provides unparalleled power. Many problems which would be difficult to express in other languages are simple in SWI-Prolog. SWI-Prolog is a 'batteries included' modern language, ready for real world tasks like web development and process control.

In this dynamic hands on workshop we'll learn the basics of SWI-Prolog, and look at some of the amazing things it can do.